[Records] Make a Record transferrable across SendPorts

[navaronbracke]

With the new Records feature being in the works, I wondered if they would be made transferrable across a SendPort.

As of now Map and List can be transferred if their data is also transferrable. But both of them can lose some typing in the process, i.e. I have to send a List<Object> or a Map<String, Object> because I need multiple arguments sent across the SendPort.

With a Record I could avoid this by creating records that suit my arguments structure.

The restriction on the datatypes inside the Record would be the same as they are with List & Map today. With the extension to the spec that for List, Map and Record a Record is now also a valid data type.

[lrhn]

We generally allow any object to be transferred to same-source isolates (those created using Isolate.spawn), and only JSON-like objects to other isolates. We do that because we know we can recreate a similar structure at the receiving end, because we can always create a native list or map.

Depending on the implementation strategy, it's not clear that every record shape will be representable in every Dart program. It's quite possible, maybe even desirable, to have a runtime representation only for the shapes that actually occur in the program, and no way to represent other shapes. Sending an arbitrary record to an isolate compiled with that kind of tree-shaking means that it may not be able to represent the result.

I'd prefer to not allow sending records to arbitrary isolates, only to same-source isolates, where we'd allow it anyway because we can send almost anything. You'd still have to, effectively, JSON-encode the data before sending it to a foreign isolate.

[alexmarkov]

In order to support dynamic invocations of record field getters AOT now tracks all possible shapes of record objects in a program. Record shapes which were not present during compilation are not allowed at runtime (as they can potentially introduce new getters).

This means that sending/receiving records of arbitrary shapes between different isolate groups would not be correct in AOT mode, unless we change how dynamic invocations are handled in AOT. Such a change is likely to affect performance of all code involving dynamic invocations (as any dynamic invocation can potentially hit a record field with the same name sent from another isolate group) and can potentially affect code size due to weaker tree shaking.

[lrhn]

Only allowing record shapes that occur in the program being compiled was a choice deliberately allowed by design, and it does prevent sending records to a different isolate group.

So, it'll be a "no" to this request. You can still send records to isolates in the same isolate group, just like almost any other object.