[swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

[Joe Groff]

> On Oct 20, 2016, at 9:42 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> Some disconnected thoughts:
> 
> - “Does not interpret” does not mean “does not preserve”. The very next sentence in the standard is "Note, however, that operations on bit strings—copy, negate, abs, copySign—specify the sign bit of a NaN result, sometimes based upon the sign bit of a NaN operand."
> 
> - If we were to claim a class of NaNs, I would pick signalling NaNs rather than positive or negative ones. AFAIK most NaN-embedding tricks avoid signalling NaNs because they can, well, signal, even though (again AFAIK) most modern systems don’t bother.

Claiming sNaNs would be unfortunate since "signaling" is about the only semantically distinct bit NaNs normally have, and I think we should minimize interference with users who are taking advantage of signaling or NaN payloads for their own means. (OTOH, on some platforms like x87 it's already practically impossible to preserve the signaling bit, since even loads will immediately raise the exception and quiet the NaN, and there would be some nice safety benefits to getting a trap early if a Float? is bitcast to a Float without being formally checked first.)

> 
> - I don’t feel like we have a coherent story here. We know that APIs taking “Double” or “Float” can represent any bit pattern. The last plan I heard for floating-point comparison treats NaNs as unordered relative to one another, even in a total order comparison. (I maintain that this is unsound.) And this proposal would treat some or all NaNs as invalid. I feel like we need to pick one approach here.

I'm not saying that they'd be invalid, only that the language doesn't guarantee to preserve these representations exactly. That seems orthogonal to the comparison issue—whatever rule we come up with for float ordering, all NaNs ought to be treated uniformly by that rule.

-Joe