Deprecate DelegatingStream.typed and make it delegate to Stream.cast

[leafpetersen]

I removed stream_test.dart since all of the functionality is really part of the SDK implementation of Stream.cast now, but if you'd prefer me to keep it around let me know.

[nex3]

This is great! Do you mind doing the same for the other Delegating*.typed() methods?

[leafpetersen]

We didn't add cast/retype to Future and StreamSubscription, so we can't do quite the same thing.

For the Future case, using

  static Future<T> typed<T>(Future future) =>
      future is Future<T> ? future : future.then((x) => x as T);

does the right thing typing wise, I think, but it doesn't handle the unwrapping/rewrapping if you cast it again.

[kevmoo]

Was this available in -dev.23?

Do we need to bump the SDK constraint?

[leafpetersen]

Yes, these APIs were available in dev.23, and all tests for this package pass with dev.23.

[leafpetersen]

Just pushed a patch removing internal uses of the now deprecated .typed method, and also ran the formatter.

[nex3]

We didn't add cast/retype to Future and StreamSubscription, so we can't do quite the same thing.

Why not? It may be useful to be able to cast the type argument of pretty much any generic class.

If we can't get rid of all the typed() methods, I'd rather leave DelegatingStream.typed() un-deprecated so that people can access these uniformly.

[leafpetersen]

Why not? It may be useful to be able to cast the type argument of pretty much any generic class.

I don't know, I wasn't part of the design discussions for these. @lrhn maybe knows?

If we can't get rid of all the typed() methods, I'd rather leave DelegatingStream.typed() un-deprecated so that people can access these uniformly.

Ok, will do.

[leafpetersen]

Done, PTAL.

[nex3]

Thanks Leaf!

[leafpetersen]

Thanks, and thanks for publishing!

[lrhn]

We didn't add cast/retype to Future and StreamSubscription, so we can't do quite the same thing.

Why not? It may be useful to be able to cast the type argument of pretty much any generic class.

We had to stop somewhere, and there didn't seem to be any cases where these were needed.

The Future isn't a collection, it's just a single value, so any time you check the type of the value, you already have the value in hand and it's as easy to create a new future as it is to wrap the existing one.

The StreamSubscription just isn't used much as a value that is passed around. You pass the stream around, and then use the subscription in one place.

Also, the await and await for syntax makes the classes less relevant. You can do:

int x = await numFuture;
await for (int y in numStream) ....

without needing to cast the future or collection first, even if you can't do numFuture.then((int x) ...) or numStream.listen((int y) ...), because they both do assignments at the value level, not the collection/future level.

So, basically, we didn't think it was worth the API complexity to add the feature. It was always mainly an Iterable and Stream (collection, really) feature, not a general feature intended for any generic class.