3 ms·

> you have to know the type of the variable to know which is which. That's not correct. The error version differs from optional by the capture on the else bran

> you have to know the type of the variable to know which is which. That's not correct. The error version differs from optional by the capture on the else branch. The optional version can't have it, and all error versions must have both captures. You can always tell which case it is just by looking at the code, without having to know the types involved.

formerly_proven 5y ago
Yes, I meant if you're looking at the if() part - you either have to know if that's an optional or an error, or go looking for the else to see if that captures an error. > because it looks exactly like the optional syntax until the else
- dnautics 5y ago
  write shorter blocks so you can see the else? If the ifs get too nested, encapsulate them in functions? Buy an extra monitor and mount it vertically (or diagonally)?
- 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.)

formerly_proven 5y ago

Yes, I meant if you're looking at the if() part - you either have to know if that's an optional or an error, or go looking for the else to see if that captures an error. > because it looks exactly like the optional syntax until the else

dnautics 5y ago
write shorter blocks so you can see the else? If the ifs get too nested, encapsulate them in functions? Buy an extra monitor and mount it vertically (or diagonally)?
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.)