[extension-types] How powerful should the show/hide part be?

[eernstg]

The extension type proposal based on #1426 includes a show/hide mechanism which allows the extension type to include a subset of the instance members of the on-type. For example:

extension type E on int show num hide floor {...}

void main() {
  E e = 42;
  e.isEven; // Error, `isEven` is not shown.
  e.ceil(); // OK, member of `num`.
  e.floor(); // Error, `floor` is not shown.
}

The proposal supports only a show clause followed by a hide clause, both optional, and it proceeds by including the members of Object?, then adding members specified by the show clause and then removing the members specified by the hide clause. Each element in these clauses can be a member name or an interface type (not an extension type).

The member name is required to be the basename of a member of the interface of the on-type (so we can't show or hide something that doesn't exist), and the interface type is required to be a superinterface of the on-type (direct or indirect).

However, this mechanism could use a lot of extra details to make the selection of included instance members more expressive and convenient.

We could also restrict the mechanism to support only member names, not types.

[Edit Mar 4 2021] Should a hide clause be allowed to hide members of Object?.

[Edit Mar 4 2021] Should the show/hide part be allowed to use a type which is not implemented by the on-type? Should hide T where T is a type hide all members of T, including Object? members?

[Edit Mar 4 2021] Should it be an error to show a member m in a type and then also declare m?

[eernstg]

@tatumizer wrote:

hide @mut

The ability to show/hide members based on anything that abstracts over members other than by referring to an interface is new and interesting. For instance, using @mut as a marker, or selecting members based on whether or not a given regexp matches the member name, selecting members based on their function type being a subtype of a specified type etc.

This is obviously quite flexible and expressive.

There is one problem at the language design level, however, because this kind of mechanism introduces a (tiny) amount of static meta-programming, and we'd want any and all static meta-programming support in Dart to add up to a coherent and consistent design. We probably also want static meta-programming to be rather clearly segregated from the rest of the language, rather than having it pop up in a lot of different language mechanisms.

For instance, we could also have implements .., <RegExp>, .. on classes, which would be the same as implements T1, .. Tk where T1, .. Tk are the types in scope that match the given regexp, or implements .., @someAnnotation, .., etc, and we could use similar mechanisms in many other parts of the language (if we think that this would be beneficial).

On the other hand, allowing multiple show/hide clauses in any order is certainly a safe bet, if we can come up with a syntax and a semantics which is considered more useful than the current <showClause>? <hideClause>? model.

[eernstg]

Another issue was raised in this topic area: Is it allowed to hide members of Object?? Added a sentence about this in the initial comment of this issue.

[eernstg]

Yet another issue was raised: Is it allowed to use a type in the show/hide part which is not implemented by the on-type? Added a sentence about this to the initial comment of this issue.

abstract class BagOfMembers { // We just want to specify some member names.
  void get length;
  void operator []=(_);
}
extension E<X> on List<X> show List hide BagOfMembers {...}

Also, should hide SomeType actually hide all members of the interface of SomeType? This would imply, for instance, that hide SomeType always hides all members of Object?, which is perhaps not likely to be the intention.

[eernstg]

Yet another issue: Is it an error when a member declaration is also shown?

extension E on int show num {
  int floor() => 1; // Error because of clash with `num.floor`?
}