Display extension members only on nullable instances of type

[FMorschel]

Today we can do things like:

extension NonNullBehavior on int {
  void doStuff() => print('non-null path');
}

extension NullableBehavior on int? {
  void doStuff() => print('nullable path');
}

And Dart will trigger the NonNullBehavior version if the type is non-null. But creating a single declaration on a Foo? type makes completion for both Foo and Foo? display the declared members.

I'd like a way to be able to declare extension members that handle the nullable versions of a type that don't clutter the non-nullable completion list.

Say I have:

class C({var bool x, var int y, var String z});

extension E on C? {
  bool isNullOrXIsFalse => this?.x ?? true;
  int nullAsZeroOrY => this?.y ?? 0;
  String defaultIfNullOrZ => this?.z ?? 'default';
}

Now all cases of both C and C? have those members on the completion list, but those are way longer and useless if we know the type is not null.

[bwilkerson]

Are you asking for a change to the language, or a change to code completion?

[FMorschel]

Since there are cases where one might want an extension member on a nullable type to show for non-nullable instances too (for simplicity), I'm asking for a way to express when I want extension members to only exist on the nullable version of a nullable type.

If that is not possible or desirable, I'll defer to requesting a way of suppressing those members on completion for non-nullable types (via annotation or something - like @visibleOnNullable).

[lrhn]

It's not that I haven't had the same need occasionally.

It'd feel a little more weird to say "extension on Comparable, but not on subtypes", so this is probably not a general feature where an extension can omit specific subtypes from being applicable.

Maybe it feels reasonable for a nullable type because it's a union type, and the operation is on the union nature itself, not the individual subtypes.
Which matches that I've wanted it on FutureOr, but definitely not on the value type.

I could also see it used on num, for an operation that distinguishes int and double values, which is unnecessary on subtypes.
But then, a sealed class is basically a union type so that checks out.

On the other hand, if there was a feature, I'm not sure it's worth only allowing it on union and sealed types. If nobody will use it for other types, it doesn't matter, and if they do find a use for it, more power to them.

How about: allow variance annotations on extension on types.
Default is in, the extension of applicable to any subtype of the (instantiated if generic) on type..
If you write on out T, a type is applicable as target if it's a supertype of the T type. (Not sure that makes sense if its not generic, and then the out should just be on the type parametet.)

But if you write on inout T, then it only applies of it matches precisely, so T? only matches a nullable type.
(Still won't help me match FutureOr<Object?>, but not Object?, they're mutual subtypes.)

If out doesn't work, and inout doesn't do what I want, maybe that's not the right approach.

So what we say on =T and it has to be precisely that type, using "same type" logic, not super/sub-typing, and no normalization (but after generic instantiation).
Then extension <T extend Object> on =T? {} would only match types that end in ?.

(Strawman syntax!!)

Could work.
It's it worth the effort and opportunity cost?
Maybe.