Should 'deriving' allows us to manually implement protocol requirements?
For example
struct A : deriving Hashable {
var hasValue : Int {...}
}
Or there should be a compilation error in this case?
Right now I feel that if we can have auto-deriving by using current syntax
for protocol conformance - we sholdn't introduce new keyword and new rules
for this.
The requirement to explicitly conform your type to protocol for
auto-deriving is IMO reasonable compromise between separate 'deriving'
decoration and implicit derivation(when your type is Hashable without any
conformance to protocol, just if each property is Hashable).
On 29.05.2016 14:42, Matthew Johnson via swift-evolution wrote:
Sent from my iPad
On May 29, 2016, at 12:28 AM, Patrick Smith <[email protected]
<mailto:[email protected]>> wrote:
Yeah I don’t see a problem. It’s the same way that protocol extensions
just work. Think of this automatic synthesis as a really flexible
protocol extension:
extension Hashable where Members : Hashable {
var hashValue : Int {
return self.allMembers.reduce(^) // Or whatever combiner is best
}
}
Protocol extensions require you to declare conformance before your type
receives their implementation and it must be identical for all do
conforming types.
You should have to declare conformance to receive Equatable conformance and
synthesis. IMO it makes sense to do that with 'deriving' which makes it
clear that you are requesting synthesized rather than manual conformance.
On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
The problem with this is that it doesn’t differentiate between
synthesized and manual conformance. You won’t get error messages you
otherwise would when you intend to supply manual conformance. It is
also less clear to a reader of the code that the default, compiler
synthesized implementation is being generated.
I don’t think it’s reasonable to force the language down the path where
developers don’t have to be familiar with its features in order to use
them correctly. If types in Swift were to automatically gain Equatable
and Hashable conformances whenever they were used by something that
required them, that would be a core language feature, like type
inference, that even junior developers in the language would need to
know. Yet few (though not none) would insist that all types be manually
declared, despite otherwise not knowing when our type inference goes
wrong. It’s just a basic feature of the language that anyone using the
language should know about, otherwise it can bite them in the ass when
weird compiler errors start popping up.
Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast
majority of cases where my types are trivially equatable, I should just
be able to declare them as such and gain the compiler-synthesized ==. In
the cases where that’s not possible, the compiler can emit an error. And
in the cases where I want a custom == implementation I can provide it.
Requiring a new keyword and not making this feature as simple as
possible because the rare developer with a custom type who doesn’t want
the synthesized == they just said they did by declaring Equatable
conformance is an unnecessary defaulting to the rare case.
Jon Shier
_______________________________________________
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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
