From 1d686b758774f73a3b506a57fd33fd6a53ee8f90 Mon Sep 17 00:00:00 2001 From: "Lasse R.H. Nielsen" Date: Thu, 12 Oct 2023 11:33:34 +0200 Subject: [PATCH] State that special-case `num` typing rules do not apply to extension type members. --- .../extension-types/feature-specification.md | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/accepted/future-releases/extension-types/feature-specification.md b/accepted/future-releases/extension-types/feature-specification.md index 3f3a1a8fdc..2167e53709 100644 --- a/accepted/future-releases/extension-types/feature-specification.md +++ b/accepted/future-releases/extension-types/feature-specification.md @@ -15,6 +15,10 @@ information about the process, including in their change logs. [1]: https://github.com/dart-lang/language/blob/master/working/1426-extension-types/feature-specification-views.md [2]: https://github.com/dart-lang/language/blob/master/working/extension_structs/overview.md +2023.10.12 + - State that special-case `num` typing only applies to non-extension members + invocations. + 2023.09.11 - Add missing rule about getter/setter signature correspondence. @@ -601,6 +605,28 @@ If _Dm_ is a method with function type `F`, and `args` exists, the static analysis of the extension type member invocation is the same as that of an invocation with argument part `args` of a function with the given type. +### Special-case Typing Rules for `num` Members + +The language specification contains special typing rules for invocations +of `+`, `-`, `*`, `%`, `remainder` and `clamp` methods on +subtypes of `num`, `int` and `double`. + +Those rules do *not* apply to invocations of extension or extension type +members. +The rules are otherwise unchanged when applied to non-extension type +member invocations, which will necessarily invoke the corresponding members +of an instance of `int` or `double`. + +_It's not currently possible to have a subtype of `num` which has +an extension member for those member names, but if it ever becomes possible, +the rules will still not apply to such an invocation._ + +_It's currently also not possible to introduce a subtype of `num`, `int` or +`double`, which does not have the same member signatures for the special-cased +members as the type that it subtypes, so the special-case rules are safe to +assume that signature. If we introduce the ability to narrow or change the +signatures of non-extension-type members of extension types, +the special-case typing rules will have to be re-visited._ ### Dynamic Semantics of an Extension Type Member Invocation