The edge-case I have in mind is... let's say we synthesised RawRep conformance for all Equatable raw-types. That would allow you use struct and class rawvalues with our shorthand syntax.
But Equatable values might overlap. A single raw-value might be considered equal to multiple cases in the enum. If you do that, you can get unexpected values from the initialiser, and we won't be able to check for it at compile-time, and when you try to debug these strange values, it will be in some code that isn't written down anywhere and so less obvious to debug. The only magic about Int/String literals is that the compiler understands their content and that content is known at compile-time so can be checked for uniqueness.
To be clear, though: I don't know really know why that limitation is there; but from what I've seen of the implementation this is my best guess. Otherwise there's nothing technically stopping us loosening the restrictions for the shorthand AFAIK.
On Oct 15, 2016 at 12:37 pm, <J.E. Schotsman via swift-evolution (mailto:email@example.com)> wrote:
> On 15 Oct 2016, at 01:53,Karl wrote:
> 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.
Can you give an example of such an edge case?
We may be able to exclude them somehow.
_______________________________________________ swift-evolution mailing list firstname.lastname@example.org (mailto:email@example.com) https://lists.swift.org/mailman/listinfo/swift-evolution