Skip to content
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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jayphelps
Copy link
Contributor

@jayphelps jayphelps commented Dec 15, 2023

@bobzhang
Copy link

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

@rujialiu
Copy link

Half-kidding: is it slightly better to use a "block-shaped unicode character" instead of a keyword (do etc) ? It has smaller probability that we'll regret and want to use it for another reason :)

@legezam
Copy link

legezam commented Jan 7, 2024

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 { foo: 4, bar: true } alone inherently imposes some ambiguity. F# allows you to do that and it is very challenging/disturbing sometimes when reading code not from IDE, ie without lang server backing you. You don't know what type that struct literal has. Also it sometimes makes even the compiler be puzzled about what type you want to create. I know you can specify the type of the binding itself if necessary but still, nobody does that. (at least, in the codebases that I have ever encountered)

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:
MyStruct { foo: 4, bar: true }

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 :)

@jayphelps
Copy link
Contributor Author

@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.

@hackwaly
Copy link
Contributor

hackwaly commented Jan 12, 2024

We just added MyRecord::{ ... } syntax for record creation with type specified. It will be available on next release. Thank you for your suggestion.

@zxch3n
Copy link

zxch3n commented Feb 6, 2024

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 () => { ... } is a block. To make it a record, users can use () => ({ ... })

@bobzhang
Copy link

bobzhang commented May 1, 2024

hi @jayphelps , we solved the problem by parsing {x} as record with a warning to suggest users to write in a more explicit style {x,}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants