> On 13 Jan 2017, at 23:02, Joe Groff via swift-evolution
> <[email protected]> wrote:
>
>
>> On Jan 13, 2017, at 1:10 PM, Anton Zhilin via swift-evolution
>> <[email protected]> wrote:
>>
>> That seems pretty close to Rust’s derive. Why not invent a similar syntax in
>> Swift? Otherwise it will make us look through all the sources to make sure
>> deriving is used.
>>
>> enum Option: @derive Equatable {
>> ...
>> }
>
> My feeling on this is that it feels strange to treat compiler-provided
> default implementations as different from library-provided default
> implementations. If the library provides a protocol extension with an
> appropriate default implementation for your type, you get it without any work
> on your part. While the Equatable/Hashable/Comparable conformance would most
> practically compiler generated today, you could imagine a far future version
> of Swift having sufficiently powerful generic type traits to do this in the
> library.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
It would be helpful for synthesised RawRep conformance. The inheritance-like
syntax we have now is awful - it makes people think that RawRepresentable is
some kind of magic protocol that will allow special compiler jango to happen.
You could see why they think that. This looks very much like the enum is going
to *be* an Int32:
enum Something: Int32 {
case oneThing = 36
case anotherThing = 42
}
This is also one of the icky parts to allowing tuples of integer/string
literals (something people ask for quite a lot). It would look like you’re
deriving your enum from a non-nominal type:
enum Something: (Int32, Int32) {
case oneThing = (3, 12)
case anotherThing = (5, 9)
}
Getting back to the topic: we should do this. We do it for plain enums. We do
it for tuples of Equatables. No reason we can’t do it for enums whose payloads
are Equatable tuples.
As for the broader picture on enums, my opinion is that it could be addressed
together with extending tuples and allowing them to conform to protocols. In
both cases we are expressing a conditional conformance for all (tuples/enums)
whose payload types match a set of constraints to conform to a protocol. They
would both require syntax to bind flexible numbers of (tuple elements/enum
cases) using some type constraints.
- Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
