Identity comparison with constructor sugar

[Praetonus]

This idea stems from a discussion on IRC.

A common error for new users is to use is instead of as or match to test the dynamic type of an object, resulting in code like that:

if obj is String then ...

Here, String is sugared to String.create(), which means that the identity comparison is done with a newly created object and can never be true.

We should issue a compiler error in those cases. Erroring when either operand of is is a sugared create constructor of a non-primitive type shouldn't catch legitimate cases.

One possible implementation would be during the refer pass (as this pass happens before the expr pass where the create sugar is applied). It should test whether either operand of is is a TK_TYPEREF on a non-primitive type, recursively.

[jemc]

Whoever implements this should also be sure it accounts for cases where the operand is a TK_TUPLE that includes a TK_TYPEREF, or a TK_SEQ whose final child is a TK_TYPEREF.

[Perelandric]

What about with primitives? It's useful to do if x is Foo then ... end. Then again, you can have unexpected side effects from a constructor being invoked.

[jemc]

@Perelandric - I agree with you about primitives, but @Praetonus mentioned that primitives would be exempt from this rule.

Erroring when either operand of is is a sugared create constructor of a non-primitive type shouldn't catch legitimate cases.

[Perelandric]

Thanks @jemc, I missed that.

[ehooper]

I'll take this.

[SeanTAllen]

Hi @ehooper. Awesome!

I can add you to the ponylang org as a contributor? If yes, then I can add you as the assignee on this issue.

[ehooper]

@SeanTAllen: Sure!

[SeanTAllen]

@ehooper you should have an invite. drop a note here once you've accepted and any team member can add you as the assignee. Thanks and good luck!

[ehooper]

@SeanTAllen accepted, thanks!

[SeanTAllen]

@ehooper assigned!

[ehooper]

Mentioned this in my PR, but I should have brought it up here:

I didn't include array literals in these changes, but I think those could also be an issue. For example, [1; 2; 3] is [1; 2; 3] is false, which could cause the same kind of confusion.

[Praetonus]

This is a good point @ehooper. The error message for that should include something like use a tuple if you want to compare the individual elements.

[EpicEric]

Fixed with #2494

[jemc]

Thanks for the ping, @EpicEric!