-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Static extensions] Should we allow static extensions to be accessed on any named type? #4055
Comments
No. I'd only allow adding extension static members to existing static namespaces. If we say "any type can have static members", we'll have to explain why The static namespaces are introduced by Some type aliases have a shape which we say denotes a static namespace, and we let them also alias that existing static namespace. (Which cannot be an extension namespace, since those do not introduce a type.) With this feature, some extensions will also act as extensions of the static namespaces of their (And if we did, we would not attach anything to type alias names.) To be a little more formal: An identifier or qualified identifier
A type clause
A static access on
In each case, the static namespace is searched for members with base name
With static extensions, let's go with the variant without extension NumList<T extends num> on List<T> {
factory List.sorted(Iterable<T> values) => [...values]..sort();
} will be a static extension on the static namespace denoted by When doing type inference for a static member access like
|
The current proposal (#3835) for static extensions only allows static members and constructors to be accessed only on "class-like" types (that is classes, mixin classes, mixins, enums, and extension types). In principle, we could relax this restriction, either in the case that the
on
type is a typedef (see #4052) or in the case that the receiver is a typedef name. For example, we could allow:If so, do we attach the extension to the name
Pair
or to the underlying type? That is, does the following work?cc @dart-lang/language-team
The text was updated successfully, but these errors were encountered: