[swift-evolution] Tuples as RawRepresentable

Karl razielim at gmail.com
Fri Oct 14 13:11:54 CDT 2016


> On 14 Oct 2016, at 19:56, Haravikk <swift-evolution at 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 <razielim at gmail.com <mailto:razielim at 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 <razielim at gmail.com <mailto:razielim at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> 
>>>>> On 14 Oct 2016, at 09:49, David Sweeris <davesweeris at mac.com <mailto:davesweeris at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161014/956a6b80/attachment.html>


More information about the swift-evolution mailing list