Yes exactly, use the protocol conformance syntax, Michael’s description was mistaken I think.
Just the same way you get protocol extensions without having to use a special keyword. > On 31 May 2016, at 6:26 AM, Vladimir.S via swift-evolution > <[email protected]> wrote: > > I see these two groups: both wants explicit conformance to protocols, but > first thinks that current syntax is enough (`: Equatable`) and second thinks > we should introduce new keyword `deriving` for this(`: deriving Equatable`). > I see no opinions(except the one opinion in proposal itself) to automatically > deriving without explicit decoration. > > On 30.05.2016 22:04, Michael Peternell via swift-evolution wrote: >> It seems that there are two groups here. 1) Group 1 wants Equatable (and >> others) be derived automatically unless specifically overridden: similar to >> auto-synthesis of properties in Objective-C. 2) The other group (Group 2) >> wants Equatable (and others) be derived explicitly using a `deriving` >> keyword (or something semantically equivalent). Unless I missed something, >> there were no voices for keeping the status quo, and not introducing any >> process to automatically derive these protocols. >> >> I think I chose an easy strategy when proposing the `deriving` keyword. >> Haskell is a mature language, and "copying" a feature from them is usually a >> safe choice. For each language feature, someone has to think through all the >> implications of it; this is usually far from trivial. I argue that if I take >> a feature from another language, someone has probably already thought about >> all the pros and cons of different solutions. This is just a plea for >> embracing precedent. >> >> There is one advantage of method 2 that (I think) hasn't been discussed so >> far: when you declare a type `S`, and an `Equatable` instance is >> automatically derived, there is no way to override that instance in another >> module. With method 1, there is also no way to request that an `Equatable` >> instance should *not* be generated. I think no one will vote for something >> like `struct S @notderiving(Equateble,Hashable) { ... }`. >> >> Also, a `deriving` keyword is less magical than just automatically deriving >> `Equatable` and `Hashable` instances. I think the language rules should be >> as simple as possible, by default. If you want any kind of special behavior, >> you have to ask for it: `deriving Equatable`, `@IBOutlet`, `@NSManaged`. >> Furthermore, I think it is good that the developer is aware that there is an >> "==" method somewhere, specifically for this new type. The compiler should >> not arbitrarily create methods, because someone may need them. Even if it is >> very likely that you will need them. Just like in a coffee house, you are >> asked if you want a coffee, even if you are visiting it every day. For >> example with Objective-C, I want each developer to be aware of the >> difference between a property and an iVar, and be aware of the connection >> between properties, methods, and key-value-coding. The complexities of the >> language shouldn't be hidden completely. >> >> Just my two cents.. >> >> -Michael >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
