You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I made the parser able to parse (most) any expression that ends in a right brace as alt arms without comma separators, so you can write:
alt foo {
bar => alt bar {
...
}
baz => alt baz {
...
}
}
whereas other expressions in alt arms must be comma-terminated.
As I'm converting code I think that writing in this style isn't all that clear, mostly is only useful for nested alts and, when I have multi-line alt arms it's usually most readable when the code begins on the next line.
Perhaps this amount of flexibility isn't warranted. You now have to put some thought into how best to format every case, whereas when braces were always required you didn't have any choices.
There are also some bracey expressions that don't follow the optional comma rule - records (which are going away), extensions written with braces, possibly structs (not sure how they're parsed). This makes it just a little bit more inconsistent.
Maybe just making the choice for formatting arms between => expr, and => { } was the right balance after all.
The text was updated successfully, but these errors were encountered:
Adds a new regression test suite that includes safety contracts for
`core` functions.
For that, we've also improved the memory intrinsics,
and added a few new ones.
One last change was to add a new unsupported check to
the invalid value workflow for a case that we were missing.
I made the parser able to parse (most) any expression that ends in a right brace as alt arms without comma separators, so you can write:
whereas other expressions in alt arms must be comma-terminated.
As I'm converting code I think that writing in this style isn't all that clear, mostly is only useful for nested alts and, when I have multi-line alt arms it's usually most readable when the code begins on the next line.
Perhaps this amount of flexibility isn't warranted. You now have to put some thought into how best to format every case, whereas when braces were always required you didn't have any choices.
There are also some bracey expressions that don't follow the optional comma rule - records (which are going away), extensions written with braces, possibly structs (not sure how they're parsed). This makes it just a little bit more inconsistent.
Maybe just making the choice for formatting arms between
=> expr,
and=> { }
was the right balance after all.The text was updated successfully, but these errors were encountered: