> On 10 Aug 2017, at 10:32, Martin Waitz <t...@admingilde.org> wrote:
> Hi Haravikk,
> Am 2017-08-10 11:07, schrieb Haravikk via swift-evolution:
>> I don't feel that conforming to
>> Equatable/Hashable is sufficient as an opt-in. Consider for example
>> someone who declares their type as Equatable/Hashable, then sets to
>> work on the details of their type, forgetting to implement the actual
>> equatable/hashable behaviour they want.
> This is no different than a default implementation of the protocol.
> In fact, the proposal just adds something like this:
>    extension Struct<A, B, ...>: Equatable where A: Equatable, B: Equatable, 
> ... {
>        static func ==(lhs: Self, rhs: Self) -> Bool { /* insert 
> implementation here */ }
>    }
> We don't require/support some special keywords for other protocols with 
> default implementation either,
> so I see no reason to add them here.
> Your concerns are orthogonal to this proposal and should be discussed 
> independently.

I disagree.

This is not the same as a default protocol implementation, as a default 
implementation can only act upon properties/methods that are clearly defined by 
the protocol itself. This feature by comparison is an automatic implementation 
that by design must make assumptions about the contents of a concrete type.

Consider a type that contains some kind of "volatile" data, i.e- properties 
that are not necessarily crucial to the type, and so should not be considered 
during equality. If I make a mistake and end up using the synthesised test for 
equality, then two values that should be identified as equal, will not be 
equated as such because the synthesised option cannot account for 
implementation details that it has no awareness of.

This has come up in discussion in the past, where I argued for some means of 
marking values to prevent them from being included in the synthesised 
method(s). This is covered in alternatives as "transient" values, but I 
disagree with the conclusion that this can simply be added later, as it is IMO 
crucial to the way this feature would work. Even if there were a @transient 
attribute or whatever from the start, I'd still prefer to set this within the 
context of having explicitly asked for Equatable/Hashable to be synthesised, 
and without such a feature it only makes it more crucial that the opt-in occur 
in a manner more explicit than conforming to Equatable/Hashable.

My disagreement pretty much boils down to the fact that I do not feel that 
opting in simply by conforming is sufficient given that the desired behaviour 
is assumed; I strongly feel that a more explicit declaration of "I specifically 
want to use this automatic behaviour" is required, either via attribute or 
conforming to a more explicit protocol.

I actually like the fact that conforming to Equatable requires me to implement 
==, as it ensures that I do-so, and prefer that that behaviour remain, as it 
forces me to do something about it. Even with synthesised behaviour as an 
option, it should be exactly that, an option; i.e- when my conformance to 
Equatable fails, I can choose either to implement ==, or opt-in to an automatic 
swift-evolution mailing list

Reply via email to