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 protected])> 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.
>
>
>
> Jan E.
> _______________________________________________ swift-evolution mailing list
> [email protected] (mailto:[email protected])
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
