Cyphal v1.1 should deprecate or remove the cast mode specifier (saturated/truncated)

[pavel-kirienko]

As far as I see, this appears to be a mostly unused feature. Cyphal v1.1 should make primitive casting an implementation-defined behavior.

Even if we opted for full removal, the existing tools will continue supporting the cast mode specifier for a while.

@thirtytwobits @emrainey objections?

[emrainey]

If the loss of those indicators leads to different data interpretations on either side of the communication then the protocol isn't fully specified. If the loss of the indicators has no effect on the data interpretations then they were useless? If it is a question of correctness versus speed, the protocol has to favor correctness. Is this a question of an inability to support those terms within all platforms?

[pavel-kirienko]

The cast mode does not affect wire compatibility. It is a hint to the application how to handle the case when a primitive value cannot be represented by the DSDL field it is supposed to be carried by without loss of information. For example, assigning 16 to a uint4 field will result in 0 if truncated cast mode is used, and 15 if saturated cast mode is used. In practice, pretty much all definitions do not bother to specify the cast mode, and the language defaults to saturated. My intention is to let implementations decide on the preferred strategy.