remove ambiguity of condition (x?) expression

[ekeren]

trafficstars

I tried this:

bring cloud;

let b1 = true;
let b2 : bool? = true;

if b1 == true { }
if b2 == true { }
if b1 {}
if b2 {} // this is a compilation issue

This happened:

This is surprising to me that it didn't work.

In order to fix this I've done:

if b2? {
  // actually, b is either false or true (just not nil)
} 

But the result is that b2 is either false or true (instead of just true)

I expected this:

an if condition should accept an optional statement instead of just a bool statement. This is very similar to the fact that we can use the == to compare optional<T> with T

Is there a workaround?

No response

Anything else?

No response

Wing Version

No response

Node.js Version

No response

Platform(s)

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

[eladb]

@ekeren convinced me that we can special case and allow if condition to be bool?, which will evaluate to true iff the value is defined and true.

[MarkMcCulloh]

Would this also apply to any logical expressions (e.g. b1 && b2 or !b2)?

[eladb]

Would this also apply to any logical expressions (e.g. b1 && b2 or !b2)?

Mmmm. Perhaps :) What do you think?

[ekeren]

Would this also apply to any logical expressions (e.g. b1 && b2 or !b2)?

Off the cuff, I would say yes.

I believe that if it doesn't make sense for it to work for any logical expressions it means that it might be a wrong solution.

@MarkMcCulloh , can you think of example where b1 && b2 !b2 should not work for optionals?

[MarkMcCulloh]

Might work. The compiler would have to emit code to protect against cases where we try to use a nil in logical expressions because true && null -> null in javascript and we don't want that to leak out.

Puristically this is a slippery slope, we're effectively removing the meaning of ? in bool? without explicit user involvement. Pragmatically I'm cool with trying this as long as we don't further go down the truthy/falsy path.

[ekeren]

@Chriscbr FYI, I think that the current situation doesn't make sense IMO

let b: bool? = false;
if b? {
   log("Surprise");
}

[Chriscbr]

I think there are two good options here, both of which would improve the language.

1. Remove x? syntax. From reading the comments here, it seems like the x? syntax isn't really adding clarity to code -- and in the cases highlighted in the previous comments, it's only adding ambiguity. If we didn't have this syntax, then the user's best alternative is to write x == nil or x != nil instead:

let b: bool? = false;
if b != nil {
  log("We aint nil"); // printed
}
if b == true {
  log("Not surprise"); // not printed
}

This style of code is pretty easy to write, it doesn't require consulting the language reference to use, and is easy to debug.

2. Redefine x? semantics. Here's the semantics that feels like it might have the fewest moving parts:

The syntax x? evaluates an expression x, and if its value is false or nil, the entire expression evaluates to false, otherwise it evaluates to true. Note: x can be any expression, but if x is not boolean or optional, then the compiler will raise an error since it would mean x? is always true.

[ekeren]

I like option number one, it seems like a safe bet to me. we (have if let, x! and even x?.y in the language syntax to work with nils)

If we feel that we need to support checks for nil we might circle back to the x? again.

[eladb]

+1 to remove the x? syntax.

[Chriscbr]

Looks like we have some support so let's go forward with removing this syntax (breaking change). It will be a great improvement to readability of Wing code. Existing usages of x? can be replaced with x != nil.

[CJLA]

@ekeren I would like to work on this issue

[staycoolcall911]

All yours, @CJLA!

[monadabot]

Congrats! :rocket: This was released in Wing 0.76.0.