Non-trivially serializable collectives

[john bachan]

The spec now asserts that types sent through collectives such as allreduce must be TriviallySerializable. This restriction leaves out potentially "cool" use cases such as collectives using std containers (think: set-union allreduce, broadcast of containers).

At the time of making this issue, we agreed that its too easy for a user to accidentally make a type non-trivial by declaring innocuous constructors, and so having the collective implementation automatically dispatch to the slower (non-gasnet) collective for nontrivial types could inadvertently hurt performance when the user was expecting things to be trivial. So the conclusion is to leave the triviality assertions on the existing collectives, and cook up an alternate API to opt-in to the more flexible but slower collectives when explicitly desired by the user.

[Dan Bonachea]

Non-trivial Serialization support is slated to appear in the Mar 2020 release.

[Dan Bonachea]

This was discussed in the 2020-02-12 meeting and deferred indefinitely, due to a lack of perceived demand from stakeholders.