-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unambiguous Block Expression Syntax #2
base: main
Are you sure you want to change the base?
Conversation
This proposal makes sense to me, the main issue is that we are introducing one keyword to solve syntax ambiguity, it is not very economic |
…ck-expression-syntax.md
Half-kidding: is it slightly better to use a "block-shaped unicode character" instead of a keyword ( |
Without knowing too much about the internals of the compiler, I am talking about the DX side of the lang. I have been working with both F# and Rust for some time by now and i think struct literal like In contrast to that, in rust, the type is part of the literal so it it always unambiguous both to the compiler and to the reader: If type is part of the literal, it is also unambiguous whether it is a block expression or a struct initialization. There are two wins I see here :) |
@legezam FWIW I'm with you on preferring struct initialization include the type name ahead of the curly braces. But I thought this RFC would be a less contentious way to solve the ambiguity. In actuality I prefer both suggestions, if a language overloads curly brace meaning, since I'm hopping in and out of so many other languages all the time. |
We just added |
An alternative solution may be to differentiate the two in the same way as the js arrow function. In JS, by default, the curly brace in |
hi @jayphelps , we solved the problem by parsing |
Formatted