I think Eric's idea of curly braces is worth a close look before we reject it - curly braces handle the ambiguity caused by types being expressions *much* better. ulia uses it [1]; Julia's not a dominant language but it is widely used (largely by people who also use python!) and has syntax that feels pretty python-like, so I think it's a relevant success story for curly brackats. I do think curly braces look weird at first but my guess is we'd get used to it quickly. I've never heard of it being a big barrier to new users in Julia, whereas I worry that a solution that applies inconsistently to statements vs expressions (like most of the options on the table) might be a permanent tax on users. There are good arguments *against* curly brackets that didn't apply for Julia, but I'm not convinced by any of them: (1) Julia doesn't have curly-brace-based literals. But there's no ambiguity there since a name can never be directly followed by a literal expression in the existing syntax; I don't think this would be a big problem, especially if by convention there's never a space before the open `{` (2) it might be complicated to work out f-strings rules. I'm not sure about this - I don't entirely understand the *current* rules, because for example (a) f"{g({'a': 5})}" is okay (b) f"{{'a': 5}['a']}" produces `SyntaxError: f-string: single '}' is not allowed` but it seems to me that the current rules could probably be adapted to handle type expressions in roughly the same way [1] https://docs.julialang.org/en/v1/manual/types/#man-parametric-composite-type...