> On 14 Oct 2016, at 19:11, Karl <razie...@gmail.com> wrote:
>> On 14 Oct 2016, at 19:56, Haravikk <swift-evolut...@haravikk.me
>> <mailto: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