In light of Chris and Dave's responses about how this discussion will be mostly absent of core team members until Swift 3 is more or less wrapped up, perhaps we should let this thread sit idle until then. As the original necromancer, I'm sure this will be brought back to life when it's appropriate.
Mark > On May 30, 2016, at 18:23, Patrick Smith via swift-evolution > <[email protected]> wrote: > > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
