[swift-evolution] Auto-generate op==?

[Haravikk]

> On 14 Feb 2016, at 03:44, danielt1263 at gmail.com wrote:
> 
> I don't think all that is necessary. If you don't like the default implementation for some reason, just implement it yourself. The point of this idea is to make the common case easy.
> 
> If the system you are talking about was in place, readers couldn't trust the derived implementation without first examining the entire definition. Your additions would also discourage adding other derived methods in the future. One set of annotations for Equatable, another set for Hashable, another set for DebugPrintable... Such a system would be unwieldy to say the least.
> 
> Sent from my iPad
> 
> On Feb 13, 2016, at 6:43 PM, Haravikk <swift-evolution at haravikk.me <mailto:swift-evolution at haravikk.me>> wrote:
> 
>> I discussed this recently,  there are two things that might be worth considering at the same time:
>> 
>> There should probably be an attribute so that we can indicate properties that should not be compared. This would also be a useful way to tell the compiler to ignore non-equatable values if we don’t actually care about them in the comparison.
>> It might be nice now or in future if we could also build upon the auto-generated implementation. For example, by marking properties as ignored like I say, we could then add custom code for these while still letting the compiler auto-generate the simpler cases for us.

I could say the same about any derived implementation, as you may not to check to be 100% sure that ever property is valid for the comparison. I get that extending the derived function has other complexities, but I’ve had complex types in the past (not in Swift) that would have been a lot cleaner if I could just use the derived result for most values, then tweak a few somehow. I just think it’s worth considering, even if that’s just “yeah we could do that later maybe”, but it’s a possible reason for preferring an actual keyword as it that same keyword could then be used in the extended operator.

Either way I think we still need an attribute so that properties can be opted out of the auto-generation, as it lets the feature be used on types with cache properties and other values that don’t need to be compared, which extends its usefulness to more cases; I can think of a dozen or so of my own types which essentially just have boiler-plate equality operators, but which also have properties that need to be ignored, so couldn’t make the switch to auto-generation.

Also, I just wanted to add as well that my vote’s for a derived/deriving keyword; the # prefix for compiler directives suggests to me that something may be compiled away, however if we’re using it to mark Equatable then this isn’t the case as the result is still always going to be Equatable. One other alternative is to just use some kind of decorative “magic” protocol, e.g- AutoEquatable (extending Equatable) that is handled with some compiler magic in the short term, and perhaps some other mechanism in future once we get reflection and other goodies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160214/1799abfd/attachment.html>