Strict Value Semantics

[anandabits (Matthew Johnson)]

@DaveZ

Please forgive me, but the floating point signed zero debate (and its implications) was settled long before Swift. We can't revisit it.

It was settled for IEEE yes, but we have some options in Swift. See Comparable and FloatingPoint types. Whether we will revisit this is yet to be seen, but the door is not completely closed.

@DaveZ

We just need a new protocol. Call it something like Substitutable , where as @xwu aptly points out, types that conform promise that all models are considered, not just one (i.e. Equatable ).

This thread is the first time I’ve encountered this notion of needing to consider multiple models. I don’t fully grasp the implications, but it seems like the desire to consider floating point numbers a model of real numbers is the only problematic example thus far. It isn’t clear to me that this is even possible in a reasonable way as floating point numbers are able to represent values that are not reals.

@Joe_Groff

it should be the language's job to define what 'identical' means for the fundamental types and pure operations the standard library provides, and allow the definition to compose through propagation of the 'pure' constraint.

I would find it very surprising if this definition was ever inconsistent with Equatable. Is it fair to say that they will always be consistent when an Equatable conformance is provided?

Do you have any thoughts on how this would be defined for floating point types and operations? Would floating point == and < be considered pure?

It doesn’t seem like this approach is sufficient in order to suppor a third party data structure implemented from scratch using unsafe concepts. Wouldn’t the library author need to define ‘identical’ for this type? Wouldn’t we want this definition to be consistent with the definition applied by the language to fundamental types? Or did you mean that the language would also provide a clear definition of the semantics that third party libraries could also adhere to?

@Joe_Groff

As a starting point, one could use the implementation-level concept of "bitwise takable" types, which are types whose values do not depend on their storage address in memory. For such types (in practice, almost all Swift types that exist today), values with identical bit-level representations are guaranteed to be semantically equivalent.

This makes sense as a starting point, but it obviously doesn’t address types which may use different internal representations to model the same value.