Potentially eliminating the case of === #856

Activity

1. dcodeIO

   added

   enhancement

   on Sep 20, 2019
2. dcodeIO commented on Sep 20, 2019

   

   dcodeIO

   on Sep 20, 2019

   MemberAuthor

   More actions

   This turns out to be a bigger feat than expected. Because a === null compiled down to an i32.eq(a, 0) that was precomputable by Binaryen, but a A#__eq(0) isn't anymore, leading to all sorts of issues that must be solved first. Take for example

   function test(): string {
     if (a !== null) return a; // now results in an "is possibly null" error
     return "";
   }

   This a more general issue under the hood that we already have with anything that implements custom == / != overloads, but now surfaces due to applying it to strings in all cases.
3. dcodeIO commented on Sep 20, 2019

   

   dcodeIO

   on Sep 20, 2019

   Last edited by dcodeIO

   MemberAuthor

   More actions

   The easiest solution seems to be to do the identity check as an additional one to overloads that one can't override, looking somewhat like

   // equality
   i32.eq(a, b) ? true : A#__eq(a, b)
   
   // inequality
   i32.eq(a, b) ? false : A#__ne(a, b)

   but that will limit what the overloads can do in the identity-equal case and introduces a branch.

   A proper but radical solution would be to drop support for overloads entirely and build string comparison into the compiler, with alternative solutions going into the direction of building our own interpreter.

   A half-baked solution would be to disallow overriding == and != and bake only those into the compiler, but I'd say that having > etc. overloads with no way to also override == is, well, meh.
4. dcodeIO commented on Sep 21, 2019

   

   dcodeIO

   on Sep 21, 2019

   MemberAuthor

   More actions

   Currently thinking about moving null checking to the type system, adding a third reference type variant alwaysNull to the existing nullable and nonNullable variants, with the implication that flows then need a way to remember the "actual" type of locals in addition to the declared type at any given point.
5. mbrowne commented on Jun 21, 2020

   

   mbrowne

   on Jun 21, 2020

   More actions

   Why not just introduce a new operator? I think this would avoid the confusion and probably be easier to implement too. For example:

   if (a is b)
   

   There could also be a negative form:

   if (a isnt b)
   

   ...although of course that would be for convenience/readability, since if (!(a is b)) would do the same thing.
6. mbrowne commented on Jun 21, 2020

   

   mbrowne

   on Jun 21, 2020

   More actions

   ...When I wrote the above, I forgot about the fact that is is already an operator in TypeScript (used just in types, not actual executable code). But although this could potentially introduce a new confusion, I think it would be less than the confusion of repurposing ===. Or of course you could also invent some other operator, e.g. isSame.
7. cyberixae commented on Jul 15, 2020

   

   cyberixae

   on Jul 15, 2020

   More actions

   I'm expecting my AssemblyScript code to compile as TypeScript and produce a JavaScript program that works as a drop in replacement for the WebAssembly module. Both modules should ( eventually ) support loading with import and be 100% compatible so that A/B testing of TypeScript/AssemblyScript modules becomes trivial. I think such interoperability is more important than any convenience feature.
8. dcodeIO

   closed this as completedin #2157on Mar 21, 2022