[Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

Chris_Lattner · August 16, 2017, 10:29pm

Proposal Link: swift-evolution/0185-synthesize-equatable-hashable.md at master · apple/swift-evolution · GitHub

The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran from August 9…15, 2017. Feedback for the feature was glowingly positive, and the proposal is accepted. The core team discussed the concerns raised in the feedback thread for the proposal. Here are some rough notes (not intended to be exhaustive), but it is important to recognize that the proposal follows the design of the auto-synthesized Codable proposal, and that many of these same points were discussed when it came up:

- The core team feels that adding compiler magic for this case is reasonable because it solves an important user need, and doesn’t preclude the introduction of a more general feature (e.g. like a macro system, or Rust's ‘deriving’ feature) in the future. When/if that feature is designed and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds or other changes to the code. It is ok to change if fields are reordered, the standard library changes the hash function, etc. Tony pointed this out on-thread, saying: The stdlib documentation for hashValue states "Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch just needs final code review now - I think we’re all looking forward to this landing, congrats!

Chris Lattner
Review Manager

salutis · August 16, 2017, 10:35pm

This is fantastic news! Any chance of this landing in Swift 4.x instead of 5?

R+

···

On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran from August 9…15, 2017. Feedback for the feature was glowingly positive, and the proposal is accepted. The core team discussed the concerns raised in the feedback thread for the proposal. Here are some rough notes (not intended to be exhaustive), but it is important to recognize that the proposal follows the design of the auto-synthesized Codable proposal, and that many of these same points were discussed when it came up:

- The core team feels that adding compiler magic for this case is reasonable because it solves an important user need, and doesn’t preclude the introduction of a more general feature (e.g. like a macro system, or Rust's ‘deriving’ feature) in the future. When/if that feature is designed and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds or other changes to the code. It is ok to change if fields are reordered, the standard library changes the hash function, etc. Tony pointed this out on-thread, saying: The stdlib documentation for hashValue states "Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch just needs final code review now - I think we’re all looking forward to this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Nevin · August 17, 2017, 8:04pm

I am really glad this is happening, it will make implementing basic data
types much nicer, and it is exactly the sort of feature that saves
developers from having to waste time thinking about trivial rote
boilerplate both when writing and when reading code—an excellent and
welcome addition to the language.

As for Haravikk’s scenario of marking a type as Equatable to trigger an
error so you remember to implement the protocol later, you can achieve the
same goal by tagging it “MakeMeEquatable” instead. The compiler will give
an error (because there is no such protocol) and then you can come back to
fix it another time.

Nevin

···

On Wed, Aug 16, 2017 at 6:29 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Proposal Link: GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
ran from August 9…15, 2017. Feedback for the feature was glowingly
positive, and the proposal is accepted. The core team discussed the
concerns raised in the feedback thread for the proposal. Here are some
rough notes (not intended to be exhaustive), but it is important to
recognize that the proposal follows the design of the auto-synthesized
Codable proposal, and that many of these same points were discussed when it
came up:

- The core team feels that adding compiler magic for this case is
reasonable because it solves an important user need, and doesn’t preclude
the introduction of a more general feature (e.g. like a macro system, or
Rust's ‘deriving’ feature) in the future. When/if that feature is designed
and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds or
other changes to the code. It is ok to change if fields are reordered, the
standard library changes the hash function, etc. Tony pointed this out
on-thread, saying: The stdlib documentation for hashValue states "Hash
values are not guaranteed to be equal across different executions of your
program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation that
you’re getting for free from a (constrained) extension on the protocol.
This is why conformance to the protocol itself is all that is required, not
something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch
just needs final code review now - I think we’re all looking forward to
this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

John_McCall · August 16, 2017, 10:46pm

This is fantastic news! Any chance of this landing in Swift 4.x instead of 5?

It it likely to be available in 4.1, but not 4.0.

John.

···

On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution <swift-evolution@swift.org> wrote:

R+

On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran from August 9…15, 2017. Feedback for the feature was glowingly positive, and the proposal is accepted. The core team discussed the concerns raised in the feedback thread for the proposal. Here are some rough notes (not intended to be exhaustive), but it is important to recognize that the proposal follows the design of the auto-synthesized Codable proposal, and that many of these same points were discussed when it came up:

- The core team feels that adding compiler magic for this case is reasonable because it solves an important user need, and doesn’t preclude the introduction of a more general feature (e.g. like a macro system, or Rust's ‘deriving’ feature) in the future. When/if that feature is designed and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds or other changes to the code. It is ok to change if fields are reordered, the standard library changes the hash function, etc. Tony pointed this out on-thread, saying: The stdlib documentation for hashValue states "Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch just needs final code review now - I think we’re all looking forward to this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

salutis · August 16, 2017, 10:59pm

That's great. Thanks!

R+

···

On 17 Aug 2017, at 00:46, John McCall <rjmccall@apple.com> wrote:

On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution <swift-evolution@swift.org> wrote:

This is fantastic news! Any chance of this landing in Swift 4.x instead of 5?

It it likely to be available in 4.1, but not 4.0.

John.

R+

On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran from August 9…15, 2017. Feedback for the feature was glowingly positive, and the proposal is accepted. The core team discussed the concerns raised in the feedback thread for the proposal. Here are some rough notes (not intended to be exhaustive), but it is important to recognize that the proposal follows the design of the auto-synthesized Codable proposal, and that many of these same points were discussed when it came up:

- The core team feels that adding compiler magic for this case is reasonable because it solves an important user need, and doesn’t preclude the introduction of a more general feature (e.g. like a macro system, or Rust's ‘deriving’ feature) in the future. When/if that feature is designed and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds or other changes to the code. It is ok to change if fields are reordered, the standard library changes the hash function, etc. Tony pointed this out on-thread, saying: The stdlib documentation for hashValue states "Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch just needs final code review now - I think we’re all looking forward to this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

anandabits · August 16, 2017, 11:02pm

That's great. Thanks!

Yes, excellent news! I am *really* looking forward to seeing this proposal make it into an Xcode release!

···

On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution <swift-evolution@swift.org> wrote:

R+

On 17 Aug 2017, at 00:46, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This is fantastic news! Any chance of this landing in Swift 4.x instead of 5?

It it likely to be available in 4.1, but not 4.0.

John.

R+

On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran from August 9…15, 2017. Feedback for the feature was glowingly positive, and the proposal is accepted. The core team discussed the concerns raised in the feedback thread for the proposal. Here are some rough notes (not intended to be exhaustive), but it is important to recognize that the proposal follows the design of the auto-synthesized Codable proposal, and that many of these same points were discussed when it came up:

- The core team feels that adding compiler magic for this case is reasonable because it solves an important user need, and doesn’t preclude the introduction of a more general feature (e.g. like a macro system, or Rust's ‘deriving’ feature) in the future. When/if that feature is designed and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds or other changes to the code. It is ok to change if fields are reordered, the standard library changes the hash function, etc. Tony pointed this out on-thread, saying: The stdlib documentation for hashValue states "Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch just needs final code review now - I think we’re all looking forward to this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

bob · August 16, 2017, 11:05pm

How do unstable hash values play with Codable? If you encode and save a Set, might you have problems interacting with it in the future? (This is more a Codable question than Hashable, but I figure I might as well ask here)

···

On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution <swift-evolution@swift.org> wrote:

That's great. Thanks!

Yes, excellent news! I am *really* looking forward to seeing this proposal make it into an Xcode release!

R+

On 17 Aug 2017, at 00:46, John McCall <rjmccall@apple.com> wrote:

On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution <swift-evolution@swift.org> wrote:

This is fantastic news! Any chance of this landing in Swift 4.x instead of 5?

It it likely to be available in 4.1, but not 4.0.

John.

R+

On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran from August 9…15, 2017. Feedback for the feature was glowingly positive, and the proposal is accepted. The core team discussed the concerns raised in the feedback thread for the proposal. Here are some rough notes (not intended to be exhaustive), but it is important to recognize that the proposal follows the design of the auto-synthesized Codable proposal, and that many of these same points were discussed when it came up:

- The core team feels that adding compiler magic for this case is reasonable because it solves an important user need, and doesn’t preclude the introduction of a more general feature (e.g. like a macro system, or Rust's ‘deriving’ feature) in the future. When/if that feature is designed and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds or other changes to the code. It is ok to change if fields are reordered, the standard library changes the hash function, etc. Tony pointed this out on-thread, saying: The stdlib documentation for hashValue states "Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch just needs final code review now - I think we’re all looking forward to this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · August 17, 2017, 3:01am

If I understand the question correctly, Robert's asking whether the
possibility that hashes might differ on every execution would causes issues
if, upon deserializing, one stumbles upon a hash collision which did not
occur with the original hashes. And I suppose the answer to that is...yes?

···

On Wed, Aug 16, 2017 at 6:16 PM, Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote:

From what I can tell the hash values of elements in a Set don't come into
play during encoding/decoding: they're merely serialized as the sequence of
their elements. https://github.com/apple/swift/blob/
2e5817ebe15b8c2fc2459e08c1d462053cbb9a99/stdlib/public/core/
Codable.swift#L4073-L4097

On Wed, Aug 16, 2017 at 4:06 PM Robert Bennett via swift-evolution < > swift-evolution@swift.org> wrote:

How do unstable hash values play with Codable? If you encode and save a
Set, might you have problems interacting with it in the future? (This is
more a Codable question than Hashable, but I figure I might as well ask
here)

On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution < >> swift-evolution@swift.org> wrote:

On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution < >> swift-evolution@swift.org> wrote:

That's great. Thanks!

Yes, excellent news! I am *really* looking forward to seeing this
proposal make it into an Xcode release!

R+

On 17 Aug 2017, at 00:46, John McCall <rjmccall@apple.com> wrote:

On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution < >> swift-evolution@swift.org> wrote:

This is fantastic news! Any chance of this landing in Swift 4.x instead
of 5?

It it likely to be available in 4.1, but not 4.0.

John.

R+

On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote:

Proposal Link: GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
ran from August 9…15, 2017. Feedback for the feature was glowingly
positive, and the proposal is accepted. The core team discussed the
concerns raised in the feedback thread for the proposal. Here are some
rough notes (not intended to be exhaustive), but it is important to
recognize that the proposal follows the design of the auto-synthesized
Codable proposal, and that many of these same points were discussed when it
came up:

- The core team feels that adding compiler magic for this case is
reasonable because it solves an important user need, and doesn’t preclude
the introduction of a more general feature (e.g. like a macro system, or
Rust's ‘deriving’ feature) in the future. When/if that feature is designed
and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds
or other changes to the code. It is ok to change if fields are reordered,
the standard library changes the hash function, etc. Tony pointed this out
on-thread, saying: The stdlib documentation for hashValue states "Hash
values are not guaranteed to be equal across different executions of your
program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation
that you’re getting for free from a (constrained) extension on the
protocol. This is why conformance to the protocol itself is all that is
required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The
patch just needs final code review now - I think we’re all looking forward
to this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

allevato · August 16, 2017, 11:15pm

From what I can tell the hash values of elements in a Set don't come into

play during encoding/decoding: they're merely serialized as the sequence of
their elements.

github.com

apple/swift/blob/2e5817ebe15b8c2fc2459e08c1d462053cbb9a99/stdlib/public/core/Codable.swift#L4073-L4097


      
          extension Set : Encodable /* where Element : Encodable */ {
              public func encode(to encoder: Encoder) throws {
                  assertTypeIsEncodable(Element.self, in: type(of: self))
          
                  var container = encoder.unkeyedContainer()
                  for element in self {
                      try (element as! Encodable).__encode(to: &container)
                  }
              }
          }
          
          extension Set : Decodable /* where Element : Decodable */ {
              public init(from decoder: Decoder) throws {
                  // Initialize self here so we can get type(of: self).
                  self.init()
                  assertTypeIsDecodable(Element.self, in: type(of: self))
          
                  let metaType = (Element.self as! Decodable.Type)
                  var container = try decoder.unkeyedContainer()
                  while !container.isAtEnd {

This file has been truncated. show original

···

On Wed, Aug 16, 2017 at 4:06 PM Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote:

How do unstable hash values play with Codable? If you encode and save a
Set, might you have problems interacting with it in the future? (This is
more a Codable question than Hashable, but I figure I might as well ask
here)

On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution < > swift-evolution@swift.org> wrote:

That's great. Thanks!

Yes, excellent news! I am *really* looking forward to seeing this
proposal make it into an Xcode release!

R+

On 17 Aug 2017, at 00:46, John McCall <rjmccall@apple.com> wrote:

On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution < > swift-evolution@swift.org> wrote:

This is fantastic news! Any chance of this landing in Swift 4.x instead of
5?

It it likely to be available in 4.1, but not 4.0.

John.

R+

On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

Proposal Link:
https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
ran from August 9…15, 2017. Feedback for the feature was glowingly
positive, and the proposal is accepted. The core team discussed the
concerns raised in the feedback thread for the proposal. Here are some
rough notes (not intended to be exhaustive), but it is important to
recognize that the proposal follows the design of the auto-synthesized
Codable proposal, and that many of these same points were discussed when it
came up:

- The core team feels that adding compiler magic for this case is
reasonable because it solves an important user need, and doesn’t preclude
the introduction of a more general feature (e.g. like a macro system, or
Rust's ‘deriving’ feature) in the future. When/if that feature is designed
and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds or
other changes to the code. It is ok to change if fields are reordered, the
standard library changes the hash function, etc. Tony pointed this out
on-thread, saying: The stdlib documentation for hashValue states "Hash
values are not guaranteed to be equal across different executions of your
program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation that
you’re getting for free from a (constrained) extension on the protocol.
This is why conformance to the protocol itself is all that is required, not
something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch
just needs final code review now - I think we’re all looking forward to
this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

allevato · August 17, 2017, 3:40am

So the concern is that you have a Set of values with derived hashes, it
gets encoded, and then a later run of the program decodes that payload, the
hash values are different and performance suffers because collisions occur
where they previously didn't? (Correctness would never be an issue, since
collisions would still be resolved by testing equality.)

*Technically* that's possible, I suppose, if (1) the developer reordered
the fields between runs, (2) the implementation of the hash function
changed between language versions, or (3) it involved some sort of runtime
nondeterminism or randomness. If we ignore the cases where the code or the
runtime has to be recompiled, then only (3) applies, and I don't foresee
the derived hashes being implemented non-deterministically.

For what it's worth, this doesn't seem like a problem that's unique to
synthesized requirements—it could happen with any type that changed its
hash or introduced nondeterminism.

···

On Wed, Aug 16, 2017 at 8:01 PM Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

If I understand the question correctly, Robert's asking whether the
possibility that hashes might differ on every execution would causes issues
if, upon deserializing, one stumbles upon a hash collision which did not
occur with the original hashes. And I suppose the answer to that is...yes?

On Wed, Aug 16, 2017 at 6:16 PM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote:

From what I can tell the hash values of elements in a Set don't come into
play during encoding/decoding: they're merely serialized as the sequence of
their elements.
https://github.com/apple/swift/blob/2e5817ebe15b8c2fc2459e08c1d462053cbb9a99/stdlib/public/core/Codable.swift#L4073-L4097

On Wed, Aug 16, 2017 at 4:06 PM Robert Bennett via swift-evolution < >> swift-evolution@swift.org> wrote:

How do unstable hash values play with Codable? If you encode and save a
Set, might you have problems interacting with it in the future? (This is
more a Codable question than Hashable, but I figure I might as well ask
here)

On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution < >>> swift-evolution@swift.org> wrote:

On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution < >>> swift-evolution@swift.org> wrote:

That's great. Thanks!

Yes, excellent news! I am *really* looking forward to seeing this
proposal make it into an Xcode release!

R+

On 17 Aug 2017, at 00:46, John McCall <rjmccall@apple.com> wrote:

On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution < >>> swift-evolution@swift.org> wrote:

This is fantastic news! Any chance of this landing in Swift 4.x instead
of 5?

It it likely to be available in 4.1, but not 4.0.

John.

R+

On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution < >>> swift-evolution@swift.org> wrote:

Proposal Link:
https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md

The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
ran from August 9…15, 2017. Feedback for the feature was glowingly
positive, and the proposal is accepted. The core team discussed the
concerns raised in the feedback thread for the proposal. Here are some
rough notes (not intended to be exhaustive), but it is important to
recognize that the proposal follows the design of the auto-synthesized
Codable proposal, and that many of these same points were discussed when it
came up:

- The core team feels that adding compiler magic for this case is
reasonable because it solves an important user need, and doesn’t preclude
the introduction of a more general feature (e.g. like a macro system, or
Rust's ‘deriving’ feature) in the future. When/if that feature is designed
and built, the compiler magic can be replaced with standard library magic.

- The hash value of a type is not intended to be stable across rebuilds
or other changes to the code. It is ok to change if fields are reordered,
the standard library changes the hash function, etc. Tony pointed this out
on-thread, saying: The stdlib documentation for hashValue states "Hash
values are not guaranteed to be equal across different executions of your
program. Do not save hash values to use during a future execution.”

- The code synthesized is meant to feel like a default implementation
that you’re getting for free from a (constrained) extension on the
protocol. This is why conformance to the protocol itself is all that is
required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The
patch just needs final code review now - I think we’re all looking forward
to this landing, congrats!

Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Haravikk3 · August 17, 2017, 8:11am

How do unstable hash values play with Codable? If you encode and save a Set, might you have problems interacting with it in the future? (This is more a Codable question than Hashable, but I figure I might as well ask here)

I'm not big on the specifics of Codable, but collections are usually a case where you need to be careful about how exactly you encode them; i.e- you usually only want to encode the length and the contents, not anything related to the way in which they are actually stored. This way it doesn't matter if the hashes change, as you recreate the Set like you're adding all the values for the first time; any collisions should then be resolved as normal (i.e- assigning into buckets of non-identical items with the same hash). Nothing in a Set should ever be overwritten on the basis of its hash alone. Otherwise, any code that requires a more stable hash value should be using something other than Hashable to generate it.

···

On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

I still strongly feel that treating this like a default implementation is a mistake, especially in the case of Equatable; we are literally talking here about a feature that introduces the potential to hide bugs, and it is not the same as a default implementation, not at all as it uses details of the concrete type, rather than merely what is defined within the protocol itself, you are talking here about using parts of a type that are not clearly defined, to create an implementation that by its very nature must give accurate results.

I mean, the whole point of a protocol is to define what we as developers need to do in order to ensure correct behaviour; when we start talking about providing that behaviour automatically with behind the scenes magic that necessarily has to make assumptions about a type then you lose any ability to guarantee correctness. I feel so strongly that this is a mistake that I would rather never see this feature implemented than see it implemented in this way, and feel that this concern has been trivialised and ignored.

bob · August 17, 2017, 10:42am

Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint, so I don’t think there is an issue here.

···

On Aug 17, 2017, at 4:12 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

How do unstable hash values play with Codable? If you encode and save a Set, might you have problems interacting with it in the future? (This is more a Codable question than Hashable, but I figure I might as well ask here)

I'm not big on the specifics of Codable, but collections are usually a case where you need to be careful about how exactly you encode them; i.e- you usually only want to encode the length and the contents, not anything related to the way in which they are actually stored. This way it doesn't matter if the hashes change, as you recreate the Set like you're adding all the values for the first time; any collisions should then be resolved as normal (i.e- assigning into buckets of non-identical items with the same hash). Nothing in a Set should ever be overwritten on the basis of its hash alone. Otherwise, any code that requires a more stable hash value should be using something other than Hashable to generate it.

On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

I still strongly feel that treating this like a default implementation is a mistake, especially in the case of Equatable; we are literally talking here about a feature that introduces the potential to hide bugs, and it is not the same as a default implementation, not at all as it uses details of the concrete type, rather than merely what is defined within the protocol itself, you are talking here about using parts of a type that are not clearly defined, to create an implementation that by its very nature must give accurate results.

I mean, the whole point of a protocol is to define what we as developers need to do in order to ensure correct behaviour; when we start talking about providing that behaviour automatically with behind the scenes magic that necessarily has to make assumptions about a type then you lose any ability to guarantee correctness. I feel so strongly that this is a mistake that I would rather never see this feature implemented than see it implemented in this way, and feel that this concern has been trivialised and ignored.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Haravikk3 · August 17, 2017, 12:00pm

And I disagree; this isn't a constraint extension either, not even close, we're talking here about automatic behaviour based upon variables the protocol knows literally nothing about, in a way that can result in new errors that are currently impossible (as you can't currently conform to Equatable without providing some kind of code to implement it).

It is no more comparable to a constrained extension than it is to a default implementation, as it is neither of these things; both of those are well defined by their very nature, this instead is utterly arbitrary. There is no justification that will make that any less true.

···

On 17 Aug 2017, at 11:42, Robert Bennett <rltbennett@icloud.com> wrote:

Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint, so I don’t think there is an issue here.

Chris_Lattner · August 17, 2017, 5:04pm

I understand and recognize your concern. Your points are apply equally to the default implementation of the Codable protocols as well, and the core team specifically discussed this.

Also, if I were to nitpick your argument a bit, it isn’t true that the protocol knows “nothing" about the type anyway, because the protocol has access to self. The default implementation could conceptually use reflection to access all the state in the type: we’re producing the same effect with more efficient code.

-Chris

···

On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 17 Aug 2017, at 11:42, Robert Bennett <rltbennett@icloud.com <mailto:rltbennett@icloud.com>> wrote:

Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint, so I don’t think there is an issue here.

And I disagree; this isn't a constraint extension either, not even close, we're talking here about automatic behaviour based upon variables the protocol knows literally nothing about, in a way that can result in new errors that are currently impossible (as you can't currently conform to Equatable without providing some kind of code to implement it).

Haravikk3 · August 17, 2017, 6:10pm

Parts that the protocol specifically defines are fine, I've said as much; the part I object to is everything else as the issue here is that the protocol must make assumptions about the concrete type and I find that dangerous, especially on an existing protocol. I would argue that any default implementation using reflection to do the same is likewise flawed unless the behaviour is very carefully and very clearly defined as part of a contract that developers are explicitly opting in to.

But that's not what's happening here; Equatable is an existing and well understood protocol and you are proposing to change it arbitrarily to suddenly imply functionality that doesn't currently exist and which has the potential to introduce bugs.

I have seen not one shred of justification why this feature must be implicit through Equatable except that Codable does it, and frankly I don't find that even close to acceptable as a precedent at all as Codable is not preexisting, and personally I don't like it in Codable's case either, and wasn't aware of the discussion around it. But for Equatable we're talking about a preexisting protocol that will today catch 100% of missing conformance bugs, being changed such that that is no longer the case because of a default behaviour that will hide such bugs by making potentially flawed assumptions about a concrete type.

Frankly, setting a precedent for this kind of automated background reflective guesswork on basic protocols is a horrifying prospect to me, even more so if it is being introduced arbitrarily on existing protocols. At least with things like unit testing that reflect test methods the rules are clearly known from the outset (i.e- there's a clear naming convention for what is reflected, everything else is the developer's domain, you opt-in by following that naming convention), this is not the case here.

And what exactly is the burden from opting in explicitly? A different protocol name, a keyword or an attribute are not going to trouble developers, and will clarify exactly what they intended without hiding bugs. This is why I feel this hasn't been considered sufficiently at all, as no justification is given why "AutoEquatable" or whatever is somehow an unacceptable burden to clarify what a developer actually wanted.

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.

This is an overreach, plain and simple. While it may seem small, I would frankly rather go back to coding everything in C++ than continue using Swift if this is to be the direction of travel, as there's a big a difference between convenience and trying to guess what a developer wanted. Cutting down on boilerplate is a fine goal, but it should be because I as the developer wanted it, not someone else who thinks they're doing me a favour despite knowing nothing about my code.

···

On 17 Aug 2017, at 18:04, Chris Lattner <clattner@nondot.org> wrote:

On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 17 Aug 2017, at 11:42, Robert Bennett <rltbennett@icloud.com <mailto:rltbennett@icloud.com>> wrote:

Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint, so I don’t think there is an issue here.

And I disagree; this isn't a constraint extension either, not even close, we're talking here about automatic behaviour based upon variables the protocol knows literally nothing about, in a way that can result in new errors that are currently impossible (as you can't currently conform to Equatable without providing some kind of code to implement it).

I understand and recognize your concern. Your points are apply equally to the default implementation of the Codable protocols as well, and the core team specifically discussed this.

Also, if I were to nitpick your argument a bit, it isn’t true that the protocol knows “nothing" about the type anyway, because the protocol has access to self. The default implementation could conceptually use reflection to access all the state in the type: we’re producing the same effect with more efficient code.

CTMacUser · August 18, 2017, 1:34pm

I’ve proposed having alternative types (strong type-alias / subtypes / quotient types) in the recent past. A key feature is selectively copying the underlying type’s interface:

alter PlagiarizedArray<T>: Array<T>, MutableCollection {

// Copy the interface of Array’s RandomAccessCollection, and forward them to super
publish RandomAccessCollection

/* Don’t do the same for MutableCollection. Either reverse that decision or implement the needed methods (that aren’t already part of RandomAccessCollection) manually. */
//...

}

So, with these new/changed protocols, an alternative that declares conformance to Equatable / Hashable / Encodable / Decodable would effectively get a “publish Whatever” no-so-secretly added, right? That could mess up selective copying of the interface. Of course, both my method and synthesized conformance would just effectively forward to super, so is it a distinction without a difference?

I want alternative types in Swift 5. (They shouldn’t be too hard to implement. I’ve downloaded the compiler’s Git archive to try it out.) Once added, we will have a way to declare implicitly accessible methods, making the synthesized conformance here obsolete. At that point I think we should declare as such and require explicit “publish Equatable/Hashable/Encodable/Decodable/Codable” directives in non-alternatives declaring conformance.

A new problem is that (at least) one version of Swift would have come out by then. Would requiring explicit publishing break backwards compatibility? Could we migrate the code by suggesting to insert the appropriate publishing directives? Could we have a compatibility mode where these five protocols’ implicit synthesizing is grandfathered in, but all new protocols important enough to get this status must need an explicit directive?

···

On Aug 17, 2017, at 1:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 17 Aug 2017, at 11:42, Robert Bennett <rltbennett@icloud.com <mailto:rltbennett@icloud.com>> wrote:

Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint, so I don’t think there is an issue here.

And I disagree; this isn't a constraint extension either, not even close, we're talking here about automatic behaviour based upon variables the protocol knows literally nothing about, in a way that can result in new errors that are currently impossible (as you can't currently conform to Equatable without providing some kind of code to implement it).

I understand and recognize your concern. Your points are apply equally to the default implementation of the Codable protocols as well, and the core team specifically discussed this.

Also, if I were to nitpick your argument a bit, it isn’t true that the protocol knows “nothing" about the type anyway, because the protocol has access to self. The default implementation could conceptually use reflection to access all the state in the type: we’re producing the same effect with more efficient code.

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

Tino · August 19, 2017, 10:44am

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

···

Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution <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.

Haravikk3 · August 19, 2017, 11:06am

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 realise I may seem to be overreacting, but I really do feel that strongly about what I fully believe is a mistake. I understand people's enthusiasm for the feature, I do; I hate boilerplate as much as the next developer, but as you say, it's not a reason to rush forward, especially when this is not something that can be easily changed later.

That's a big part of the problem; the decisions here are not just about trimming boilerplate for Equatable/Hashable, it's also about the potential overreach of every synthesised feature now and in the future as well.

···

On 19 Aug 2017, at 11:44, Tino Heth <2th@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

CTMacUser · August 19, 2017, 6:46pm

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?

···

On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 19 Aug 2017, at 11:44, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:

Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

I realise I may seem to be overreacting, but I really do feel that strongly about what I fully believe is a mistake. I understand people's enthusiasm for the feature, I do; I hate boilerplate as much as the next developer, but as you say, it's not a reason to rush forward, especially when this is not something that can be easily changed later.

That's a big part of the problem; the decisions here are not just about trimming boilerplate for Equatable/Hashable, it's also about the potential overreach of every synthesised feature now and in the future as well.

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

xwu · August 19, 2017, 6:05pm

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.

This was already touched upon during review, but to reiterate, the analogy
to default protocol implementations is meant specifically to address this
point about "hiding bugs." Yes, this feature cannot currently be
implemented as a default protocol implementation without magic; with better
reflection facilities there's a good chance that one day it might be, but
that's not the reason why it's being compared to default protocol
implementations. The reason for the comparison is that this feature only
"hides bugs" like a default protocol implementation "hides bugs" (in the
I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won't-remind-me-anymore
sense of "hiding bugs"), and the addition of default protocol
implementations, unless I'm mistaken, isn't even considered an API change
that requires Swift Evolution review.

Given Swift's emphasis on progressive disclosure, I'm fairly confident that
once reflection facilities and/or code-generation facilities improve, many
boilerplate-y protocol requirements will be given default implementations
where they cannot be written today. With every advance in expressiveness,
more protocol requirements that cannot currently have a default
implementation will naturally acquire them. Since the degree to which the
compiler will cease to give errors about non-implementation is directly in
proportion to the boilerplate reduced, it's not a defect but a feature that
these compiler errors go away. At the moment, it is a great idea to enable
some of these improvements for specific common use cases before the general
facilites for reflection and/or code-generation are improved in later
versions of Swift, since the user experience would be expected to remain
the same once those full facilities arrive.

I realise I may seem to be overreacting, but I really do feel that strongly

···

On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

On 19 Aug 2017, at 11:44, Tino Heth <2th@gmx.de> wrote:
Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution < > swift-evolution@swift.org>:
about what I fully believe is a mistake. I understand people's enthusiasm
for the feature, I do; I hate boilerplate as much as the next developer,
but as you say, it's not a reason to rush forward, especially when this is
not something that can be easily changed later.

That's a big part of the problem; the decisions here are not just about
trimming boilerplate for Equatable/Hashable, it's also about the potential
overreach of every synthesised feature now and in the future as well.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution