Extension type new syntax available in dart Dart 3.3.0-174.2.beta, some questions and thoughts

[brilliapps]

Normally i ask on the dart official discord server. Comments in the code are describing what is happening and why something else could happen in some cases, what i see, and what in my opinion (limited knowledge) would cause the "extension type" to be perfect.
Please take note that there is here below a new type Int defined, starting from a big letter I (not "int"). Also there may be similar situations like these below, but this is enough for now.

extension type Int(int i) implements int {
  Int operator +(int other) {
    return Int(i + other);
  }
}

void main() {
  int a = 2;
  Int b = Int(8); // coulndn't Int b = 8? and silently cast as Int?

  b = b + a; // wrong, but Int + operator overriden returns Int
  b = a + b; // wrong, because a is int, but couldn't it be silently cast to Int?
  a = a + b; // good as expected.
  print(b + a); // ok, somewhere toString is called for sure.
  print(b + b);
  print(a + b);
}

So, do you think that at least b = b + a shouldn't be marked as error in my VScode? I imagined a reason why it should, but i don't know. Any opinions?

[lrhn]

Yes, b = b + a; should not be an error.

The missing piece of the implementation is that the special rules for number operator typing should not apply to the extension type operator.

Normally a + a has type int, which is different from the declared return type of int.operator+, which is num.
That's great, and makes number arithmetics bearable.
While b is-an int, its operator+ is not the one that the special typing applies to. I'm guessing the implementation fails to recognize that.

So, for every special rules about number operation typing, it should be read as having an additional "if the invoked member is a non-extension-type member". That restriction was really always there, it was just not necessary to say so, because it couldn't not be that. Now it can.

[lrhn]

About the silent coercion from int to Int, we've chosen to not do that.
That allows an extension type to expose only public constructors which do more than just inject a value.
If we allow done values to be implicitly downcast to the extension subtype, extension type authors would also need a way to opt out of that.

If we introduce implicit coercions at some point, they will likely also apply to extension types, and allowing some simple type coercions now may get in the way of doing a more general thing in the future.

So not letting you do Int b = 8; is very much deliberate. That's an implicit downcast, and we just got rid of those with null safety.

[brilliapps]

If we allow done values to be implicitly downcast to the extension subtype, extension type authors would also need a way to opt out of that.

If we introduce implicit coercions at some point, they will likely also apply to extension types, and allowing some simple type coercions now may get in the way of doing a more general thing in the future.`

I conclude, speaking in very simple terms from the above that a "feature" can be implemented in some future that will allow maybe not Int b = 8 but at least, based on my initial example code this:
b = a + b; // will be fine one day :)

When might such a thing be implemented if so? A year?, half a year?

[lrhn]

I'd say that if we introduce implicit coercions (which a type will have to opt into somehow), then you will be able to declare a coercion from int to Int, and then both Int b = 8; and b = a + b; should work with that.

Absolutely no guarantees that it will happen or, if it does, when.

[brilliapps]

Thank you for your answers. Implementing the coercion (with any "but" and "opt-out") would nail it, imho.

Please, if you sees it fit, you can close this issue. But by not doing it some people may have their opinion on this. And again, please you decide.

[lrhn]

The bug is real and should be fixed, so keeping open for that

[brilliapps]

Ok.