ReceivePort and SendPort should be generic

[DartBot]

This issue was originally filed by bl...@google.com

---

abstract class ReceivePort<T> implements Stream<T>
and likewise
'abstract class SendPort<T> implements Capability`

There are no backwards compatibility issues because ReceivePort and SendPort will keep behaving as is.

[sethladd]

Removed Type-Defect label.
Added Type-Enhancement, Library-Isolate, Area-Library, Triaged labels.

[lrhn]

This seems like a slam-dunk on the surface, but there is a problem with adding a type parameter to SendPort.

SendPort objects can themselves be sent to any another isolate, either as isolate spawn parameters or through other send ports, but Type objects can't. If a SendPort has a type parameter, it implicitly contains a reference to that type, and then the SendPort can't be sent to, or through, another isolate that isn't equivalent to the current one (hasn't been created using only Isolate.spawn from the same original isolate, as opposed to an isolate created using Isolate.spawnUri).

We don't want to make "clever" restrictions like "a SendPort<X>" can be sent to any Isolate if X is a type in dart:core or dart:isolate, but otherwise it can only be sent to equivalent isolates". Likewise for only allowing SendPort<dynamic> to be sent to non-equivalent isolates.

One option is to lose the type parameter, which would mean defaulting it to dynamic, when the SendPort is sent to a non-equivalent isolate. That is doable, but still somewhat counter to the idea of having the type parameter, and it would look odd if the SendPort was sent back to the original isolate without the type parameter.

[lrhn]

Also, if the SendPort loses the type parameter, then it's possible to send a value that has the wrong type when it is received. That would either mean a type error on the receiving end, which is either lost or passed on the ReceivePort stream - and a ReceivePort doesn't otherwise have errors.
It's not clear what would happen for a RawReceivePort<T> if it receives a non-T value.

All in all, I don't think it's wort the compllication.

[DartBot]

This comment was originally written by @kaendfinger

---

I agree with @­lrn, this could have bad consequences.

[lrhn]

Not going to make this change right now.
If we come up with a good solution for the problems, we might revisit the idea.

---

Added NotPlanned label.