> On 19 Aug 2017, at 19:46, Daryle Walker <dary...@mac.com> wrote:
>
>> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de <mailto:2...@gmx.de>>
>>> wrote:
>>>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>>> For me the whole point of a basic protocol is that it forces me to
>>>> implement some requirements in order to conform; I can throw a bunch of
>>>> protocols onto a type and know that it won't compile until I've finished
>>>> it, developers get distracted, leave things unfinished to go back to
>>>> later, make typos etc. etc. To me declaring a conformance is a declaration
>>>> of "my type will meet the requirements for this make, sure I do it", not
>>>> "please, please use some magic to do this for me"; there needs to be a
>>>> clear difference between the two.
>>>
>>> My conclusion isn't as pessimistic as yours, but I share your objections:
>>> Mixing a normal feature (protocols) with compiler magic doesn't feel right
>>> to me — wether it's Equatable, Hashable, Codable or Error.
>>> It's two different concepts with a shared name*, so I think even
>>> AutoEquatable wouldn't be the right solution, and something like #Equatable
>>> would be a much better indicator for what is happening.
>>>
>>> Besides that specific concern, I can't fight the feeling that the evolution
>>> process doesn't work well for proposals like this:
>>> It's a feature that many people just want to have as soon as possible, and
>>> concerns regarding the long-term effects are more or less washed away with
>>> eagerness.
>>>
>>> - Tino
>>>
>>> * for the same reason, I have big concerns whenever someone proposes to
>>> blur the line between tuples and arrays
>>
>> Agreed. To be clear though; in spite of my pessimism this is a feature that
>> I do want, but I would rather not have it at all than have it implemented in
>> a way that hides bugs and sets a horrible precedent for the future.
>
> I tried to make a split thread for this, but would you object to synthesized
> conformance if we had to explicitly add a command within the definition block
> to trigger the synthesis? If we add strong type-aliases, we could reuse the
> directive to copy an interface (method, inner type, property, or conformed-to
> protocol) from the underlying type to the current type for synthesis too. The
> only problem would be backward compatibility; once added, we would urge users
> to explicitly list “publish Equatable” for synthesis, but what about code
> that already uses the implicit version (since this feature will probably be
> released for at least one Swift version by the time strong type-aliases
> happen), do we force users to change their code?
I would rather no code at all use the implicit version; one of my points is
that it's not something that's easily changed after the fact, which is why it
needs to be done correctly now.
I'm open to any method that makes opting in to the synthesised conformance
explicit; I still think a specifically named protocol is the simplest, but I'm
not married to that as a solution; attributes, keywords etc. are all fine too,
whatever is the easiest way to opt-in to the behaviour explicitly without
ambiguity. I'm not 100% sure exactly what you mean by "add a command within the
definition block", or is an attribute/keyword what you meant?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
