State that special-case num typing rules do not apply to extension type members
#3396
Conversation
|
|
||
| The language specification contains special typing rules for invocations | ||
| of `+`, `-`, `*`, `%`, `remainder` and `clamp` methods on | ||
| subtypes of `num`, `int` and `double`. |
There was a problem hiding this comment.
The subtypes of num is the same set of types (ignoring JavaScript numbers and other special number types that the language doesn't know about and implementations carefully try to hide) as the subtypes of num, int, and double.
On the other hand, the rules seem to apply to num, int, and double, and not to any other types.
Perhaps the least confusing wording would simply be '... methods on num, int, and double'?
Or perhaps type variables like X extends num justify saying 'subtypes' in any case? But even in that case we should be able to say 'subtypes of num'.
There was a problem hiding this comment.
Or just say "on instances of"...
There was a problem hiding this comment.
I think this thread can just be settled by using one of the suggested wordings.
| 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`. |
There was a problem hiding this comment.
It is slightly confusing that we're talking about non-extension type member invocations. The extension type feature specification talks about 'non-extension types', and about the 'extension type members' and 'non-extension type members' that an extension type may have, but in this case we'd like to cover plain extensions as well. We could repeat and negate 'extension or extension type members', but that's a lot of duplication just very few words apart.
So perhaps the following will suffice:
| 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`. | |
| The rules are unchanged when applied to invocations of other members, which will | |
| necessarily invoke the corresponding members of an instance of `int` or `double`. |
There was a problem hiding this comment.
I was just worried about using the phrase "non-extension type member" with a slightly different meaning than that which is used in the extension type feature specification. Would you be OK using the suggested edit?
| 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 |
There was a problem hiding this comment.
| _It's currently also not possible to introduce a subtype of `num`, `int` or | |
| _It's currently also not possible to introduce a non-extension type which is a subtype of `num`, `int` or |
| 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._ |
There was a problem hiding this comment.
Perhaps:
| the special-case typing rules will have to be re-visited._ | |
| the special-case typing rules may have to be re-visited._ |
We could claim that this case has already been covered: An extension type subtype of int, say, can certainly declare an extension type operator + with a different signature and implement it.
It would be a new thing if we allow, for example, an abstract declaration with the given name in an extension type declaration to modify the static analysis of a member whose implementation is provided by a non-extension superinterface. However, I'd suggest that we treat this case as an implicitly induced forwarding method; for instance, it would be confusing if such a member is torn off and the resulting function object doesn't have the function type of the member as declared.
|
This one has had an LGTM for a long time. I just closed a couple of discussion threads, and I don't think there's anything controversial in the remaining ones. So let's get it landed. |
The special-case rules for typing, e.g,
int + intdoes not apply if+denotes an extension type member,even if the receiver is a subtype of
int.