Yes it absolutely matters what the types are. Two floating point values can
compare equal when their raw bytes differ and they can compare not equal
even when their raw bytes are the same, and it would be absolutely
necessary that a tuple of two floating point values behaves the same way.
Moreover, if a value is not equatable, it's nonsense to ask if tuples of
two of them are equal. Otherwise, you've effectively forced every value
type to be equatable, since it'd be ridiculous if (a, a) == (b, b) didn't
imply a == b.
On Sat, Oct 15, 2016 at 19:44 Haravikk via swift-evolution <
> On 14 Oct 2016, at 19:11, Karl <razie...@gmail.com> wrote:
> On 14 Oct 2016, at 19:56, Haravikk <swift-evolut...@haravikk.me> wrote:
> Huh, see, that's why I posted the thread; I didn't know you could do it
> that way (I've been trying the RawRepresentable part as its own type).
> In that case yes, it seems like all that's need is an expansion of what's
> allowable on the rhs of raw value enum cases.
> And that’s why I come here - to share the little bits that I’ve learned :)
> I think a lot of people have misconceptions about what RawRep is, and the
> inheritance syntax for enums doesn’t much help that. It doesn’t affect the
> storage or layout of the enum whatsoever; it’s just a protocol conformance.
> The compiler generates these same kind of switch statements, and that’s
> really the only reason AFAIK that we have the limitations (e.g. int/string
> literal) that we do.
> There are no restrictions on what can be RawRepresentable (structs and
> classes can also conform), and no limitation on the type of RawType (can
> also be a struct or a class). You just need to implement it yourself in
> those cases; I’m guessing because there are complex edge-cases which we
> don’t want hidden away in a location you can’t easily debug.
> Tuples of Ints and Strings, however, seem like they could easily be
> supported. For example, we could check that there are no overlapping cases.
> Does the type of the tuples really matter? For equality it should be
> sufficient just to compare them directly as bytes; since they will be of
> the same tuple type this should either result in equality or not without
> too much complexity, otherwise we'd need to require the types are Equatable
> or Hashable but that seems a bit like overkill.
> I've started a preliminary proposal for tuples as enum raw value types;
> it's pretty straightforward so far as I'm not sure what more detail is
> really needed, except perhaps for this equality issue:
> swift-evolution mailing list
swift-evolution mailing list