> 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. - Karl >> On 14 Oct 2016, at 18:11, Karl Wagner <razie...@gmail.com >> <mailto:razie...@gmail.com>> wrote: >> >> Example: >> >> >> enum something { >> case onething >> case anotherthing >> } >> extension something : RawRepresentable { >> typealias RawValue = (Int, Int) >> >> init?(rawValue: something.RawValue) { >> switch rawValue { >> case (1, 1): >> self = .onething >> case (2, _): >> self = .anotherthing >> default: >> return nil >> } >> } >> >> var rawValue: (Int, Int) { >> switch self { >> case .onething: return (1, 1) >> case .anotherthing: return (2, 0) >> } >> } >> } >> >> let whatisit = something(rawValue: (1, 1)) >> something.onething.rawValue >> >> Karl >> >> Sent from my iPad >> >> On 14 Oct 2016, at 19:04, Karl Wagner <razie...@gmail.com >> <mailto:razie...@gmail.com>> wrote: >> >>> You can already do this; you just need to implement RawRep manually. >>> >>> What I think you mean to propose is that the compiler shorthand we have >>> (which synthesises the conformance if you use the equal signs next to the >>> cases) be extended to support tuples of the types it currently supports. >>> That's a relatively simple, non-source-breaking additive change. It likely >>> doesn't fit in the scope of swift 4 phase 1, though (sorry, I've been >>> guilty of chatting about non-abi stuff too as I encounter things which >>> irritate me; trying to be more disciplined) >>> >>> Karl >>> >>> Sent from my iPad >>> >>> On 14 Oct 2016, at 12:55, Haravikk via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>>> On 14 Oct 2016, at 09:49, David Sweeris <daveswee...@mac.com >>>>> <mailto:daveswee...@mac.com>> wrote: >>>>> >>>>> I'm very much in favor of the functionality, but I don't think the >>>>> implementation should rely on compiler magic. >>>>> >>>>> - Dave Sweeris >>>> >>>> Well it's not too much in the way of magic really, more just that we need >>>> Swift to see tuples as conforming to RawRepresentable and >>>> ExpressableAsTuple, although they currently aren't types in the normal >>>> sense. So the protocols being used will be the same as you might use >>>> yourself, they'll just be applied automatically for tuples. >>>> >>>> It'd be neat if it could be done properly, but that could involve even >>>> more work, but doing this automatically for now should be fairly simple >>>> (though I say that as a person who wouldn't be the one doing it ;) >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
