Constant from extension method?

[mnordine]

Any way something like this could work?

extension Time on int {
  Duration get ms => 
    Duration(microseconds: (this * Duration.microsecondsPerMillisecond).toInt());
}

main() {
  // const time = Duration(milliseconds: 250);
  const time = 250.ms;
  print(time);
}

as long as this is itself const?

[eernstg]

It is definitely pretty far away from the constants that we support today: Extension methods can never be part of a constant expression evaluation (that would enable constant evaluation to run arbitrary code), and the only non-operator member that we can evaluate in a constant is length, and that's only with an instance of String.

We have many requests for more powerful constant evaluation, but it is a very delicate area (there is no end to the complexities popping up when we consider constant evaluation together with fromEnvironment, modular compilation, and whatnot).

Granted—it looks nice! But there are lots of reasons why it won't be easy to make it happen..

(OK, here's a loophole: if we consider a compilation process where .ms is inlined prior to constant evaluation then it turns out to be an OK constant expression. But we don't have any such loophole, and I have no idea how many implications it would have to try to do such a thing. Maybe we could call this loophole "macros". But we don't have those, and it's definitely not a trivial thing to add. ;-)

[lrhn]

That "loophole" would be equivalent to having "potentially constant methods", methods which are acceptable in constant expressions because they only depend on this and other potentially constant expressions. You would have to declare such a method, so that we can check it, and it likely can't be virtual (which means it's a slam-dunk fit for extension methods). Perhaps:

class C {
   final int x;
   const C(this.x);
   const int next => x + 1;
}

Then const c0 = C(0); const c1 = C(c0.next); would b allowed because c0.next is a (potentially) const method on a const object.

That's a rather large increase in complexity and expressive power for const expressions, and we have no current plans to do add any new major features to constant expressions.

[eernstg]

Cf. dart-lang/sdk#29277, https://github.com/dart-lang/sdk/issues/20962 as well. Maybe inline could be used to mark a function as a macro, and then we could have some constraints (such as no recursion); a recursive inlining of invocations of inline functions must then yield an expression which is suitable in the given context, e.g., it may have to be a constant expression. We probably wouldn't have to support inline instance members of any kind: it could be an extension method, and it will then be resolved statically.

[jodinathan]

I thought extensions where basically a syntax sugar kind of feature based on macro.
There are packages that are being discontinued because they found out extension methods can't be const: https://pub.dev/packages/supercharged.

Other features like Duration or Color handling are ineffecient, because they can not be used with const constructors.

[rmortes]

Sorry for commenting on such an old issue, but is this feature being considered at the time?

[lrhn]

No. There is no current work being done on allowing potentially constant functions.