3 ms·

Consider the difference between an optional and an error union: An error union is a value or error. An optional is a value or null. The if/else capture synta

by jmull 5y ago

Consider the difference between an optional and an error union: An error union is a value or error. An optional is a value or null. The if/else capture syntax follows: "if" captures the value. "else" captures the error if there can be one, or doesn't capture anything if there can't. That is, you don't need (and therefore don't want) a difference between error union and optional in the if part of the syntax.

formerly_proven 5y ago
That's a fair point but doesn't really distract from the syntax being awkward for optionals. The if/else for errors matters less, at least to me, as there are already dedicated control-flow primitives for errors. [1] [1] Which reminds me that the syntax for blocks-returning-values (named blocks) is really awkward. That might be the ugliest bit of syntax in the entire language: const something = if(bar) foo else someblock: { // stuff break :someblock value_to_return; };
- jmull 5y ago
  The part I don't get with block expressions is that it requires using a label, but the label name is arbitrary/meaningless... It looks like the label serves two purposes, (1) to signal that the block returns a value and (2) so the statement that returns a value can identify the block it's returning a value for. I guess maybe three purposes, where the third is it lets the "break" keyword be overloaded for the purpose of returning a value from a block since it distinguishes it from other usages of "break". You could, e.g., drop the arbitrary label, just leave the : and it all still works unless you want to nest block expressions and return for the outer block from an inner block (which is pretty iffy, IMO, but could be supported by making the label optional). I'm not sure whether or not colons lying around is a good way to do this, just making the point that the label is arbitrary. (Maybe = or maybe <= before the block and => after break, something like that.)

by jmull 5y ago

formerly_proven 5y ago

That's a fair point but doesn't really distract from the syntax being awkward for optionals. The if/else for errors matters less, at least to me, as there are already dedicated control-flow primitives for errors. [1] [1] Which reminds me that the syntax for blocks-returning-values (named blocks) is really awkward. That might be the ugliest bit of syntax in the entire language: const something = if(bar) foo else someblock: { // stuff break :someblock value_to_return; };

jmull 5y ago
The part I don't get with block expressions is that it requires using a label, but the label name is arbitrary/meaningless... It looks like the label serves two purposes, (1) to signal that the block returns a value and (2) so the statement that returns a value can identify the block it's returning a value for. I guess maybe three purposes, where the third is it lets the "break" keyword be overloaded for the purpose of returning a value from a block since it distinguishes it from other usages of "break". You could, e.g., drop the arbitrary label, just leave the : and it all still works unless you want to nest block expressions and return for the outer block from an inner block (which is pretty iffy, IMO, but could be supported by making the label optional). I'm not sure whether or not colons lying around is a good way to do this, just making the point that the label is arbitrary. (Maybe = or maybe <= before the block and => after break, something like that.)