Open rrousselGit opened 10 months ago
Definitely an interesting idea. Yes, I believe that it's technically feasible.
If someone puts an extension on FutureOr<String>
, it could very well be because they want the operation to work on both Future<String>
and String
, not just on something explicitly typed as FutureOr<String>
.
Not showing it for a String
doesn't seem right in that case.
Not showing it for Future<String>
doesn't seem right, ever. (I something works on FutureOr<T>
, it's because it's async aware, and then it should most likely work on Future<T>
too.)
Could it be something one should opt in to? Like @onlyOnFutures extension ... on FutureOr<...>
which only appears for FutureOr<...>
or Future<...>
, because you're expected to do something more direct for known synchronous values?
Hello!
Spawned from Discord thread: https://discord.com/channels/608014603317936148/1171510601655275612/1182766954805735514
Currently if we make an
extension Name on FutureOr {...}
, whatever extension we wrote will show up everywhere.But although it makes sense from a compiler point of view for those extensions to work everywhere, from a user perspective, they pollute the autocompletion in unrelated places.
Could we do that FutureOr extensions only show-up in autocompletion if a variable is explicitly typed as
FutureOr
?Such that we have: