1

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
  static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling inside:

struct Snort: Hashable {
  synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more explicit.

2

I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the moment.

···

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <swift-evolution@swift.org> wrote:

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more explicit.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the moment.

Is this what you’re thinking of?

-Chris

···

On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

.

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <swift-evolution@swift.org> wrote:

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more explicit.
_______________________________________________
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

4

Yes, thanks! Here’s the full proposal for those interested: https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md

I think that if we want to deal with the issue of some mistake arising from conforming to Equatable and/or Hashable, it should be through that proposal, not something specific to Equatable and Hashable. This sort of issue should not count against this Equatable/Hashable proposal.

···

On Aug 10, 2017, at 3:39 PM, Chris Lattner <clattner@nondot.org> wrote:

On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the moment.

Is this what you’re thinking of?
Introducing Role Keywords to Protocol Implementations by erica · Pull Request #724 · apple/swift-evolution · GitHub

-Chris

.

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <swift-evolution@swift.org> wrote:

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more explicit.
_______________________________________________
swift-evolution mailing list
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

5

Right. The objection raised is applicable to the overriding of any default
implementation. However. _this_ proposal under review is about the
synthesis of a default implementation, and we shouldn’t try to invent new
syntax to address an orthogonal issue—and only partially at that.

···

On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote:

Yes, thanks! Here’s the full proposal for those interested:
https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md

I think that if we want to deal with the issue of some mistake arising
from conforming to Equatable and/or Hashable, it should be through that
proposal, not something specific to Equatable and Hashable. This sort of
issue should not count against this Equatable/Hashable proposal.

On Aug 10, 2017, at 3:39 PM, Chris Lattner <clattner@nondot.org> wrote:

On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution < > swift-evolution@swift.org> wrote:

I could have sworn that this sort of issue came up on this list earlier
this year… Someone proposed a mechanism encompassing all protocols, not
just Equatable and Hashable, to handle the issue of mistakenly believing
you’re overriding a default implementation. Having trouble finding it at
the moment.

Is this what you’re thinking of?
Introducing Role Keywords to Protocol Implementations by erica · Pull Request #724 · apple/swift-evolution · GitHub

-Chris

.

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution < > swift-evolution@swift.org> wrote:

If I understand it, merely adding Equatable or Hashable will cause the
compiler to synthesize requirements. This syntax opens up the possibility
for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but
misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to
"HashValue", in order to distinguish the two cases: explicit supplying the
requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some
sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do
not.

Alternatively, it might be clearer, though more verbose to move the
signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of
possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more
explicit.
_______________________________________________
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

6

As long as I've been clear that the adoption of *this* proposal would transform a misspelling from a bug that the compiler catches to a bug that the compiler does not catch, I feel that my objection has been heard.

Thank you all,

- David

···

On Aug 10, 2017, at 1:51 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Right. The objection raised is applicable to the overriding of any default implementation. However. _this_ proposal under review is about the synthesis of a default implementation, and we shouldn’t try to invent new syntax to address an orthogonal issue—and only partially at that.
On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Yes, thanks! Here’s the full proposal for those interested: https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md

I think that if we want to deal with the issue of some mistake arising from conforming to Equatable and/or Hashable, it should be through that proposal, not something specific to Equatable and Hashable. This sort of issue should not count against this Equatable/Hashable proposal.

On Aug 10, 2017, at 3:39 PM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the moment.

Is this what you’re thinking of?
Introducing Role Keywords to Protocol Implementations by erica · Pull Request #724 · apple/swift-evolution · GitHub

-Chris

.

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more explicit.
_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

7

This strikes me as another good way to look at it.

Thanks guys,

- David

···

On Aug 10, 2017, at 2:54 PM, Robert Bennett <rltbennett@icloud.com> wrote:

@Xiaodi I have a slightly different view of this. Currently, if you have a type that conforms to a protocol, and you do not need to write any additional code in order for the type to conform to the protocol, then the protocol must have default implementations of its requirements. Because some types will be able to conform to Equatable/Hashable without writing out the code to satisfy the == and hashValue requirements, that logic (which you may or may not subscribe to) would dictate that there is a default implementation of those requirements (in this case, a magical default implementation that works for many different types; maybe it uses Mirrors) — it certainly “feels” like there is a default implementation to the user. And thus from an ergonomic standpoint, these issues are not really orthogonal, even if they are distinct implementation-wise.

On Aug 10, 2017, at 5:41 PM, David Ungar <dungar@apple.com <mailto:dungar@apple.com>> wrote:

As long as I've been clear that the adoption of *this* proposal would transform a misspelling from a bug that the compiler catches to a bug that the compiler does not catch, I feel that my objection has been heard.

Thank you all,

- David

On Aug 10, 2017, at 1:51 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

Right. The objection raised is applicable to the overriding of any default implementation. However. _this_ proposal under review is about the synthesis of a default implementation, and we shouldn’t try to invent new syntax to address an orthogonal issue—and only partially at that.
On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Yes, thanks! Here’s the full proposal for those interested: https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md

I think that if we want to deal with the issue of some mistake arising from conforming to Equatable and/or Hashable, it should be through that proposal, not something specific to Equatable and Hashable. This sort of issue should not count against this Equatable/Hashable proposal.

On Aug 10, 2017, at 3:39 PM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the moment.

Is this what you’re thinking of?
Introducing Role Keywords to Protocol Implementations by erica · Pull Request #724 · apple/swift-evolution · GitHub

-Chris

.

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more explicit.
_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

8

@Xiaodi I have a slightly different view of this. Currently, if you have a type that conforms to a protocol, and you do not need to write any additional code in order for the type to conform to the protocol, then the protocol must have default implementations of its requirements. Because some types will be able to conform to Equatable/Hashable without writing out the code to satisfy the == and hashValue requirements, that logic (which you may or may not subscribe to) would dictate that there is a default implementation of those requirements (in this case, a magical default implementation that works for many different types; maybe it uses Mirrors) — it certainly “feels” like there is a default implementation to the user. And thus from an ergonomic standpoint, these issues are not really orthogonal, even if they are distinct implementation-wise.

···

On Aug 10, 2017, at 5:41 PM, David Ungar <dungar@apple.com> wrote:

As long as I've been clear that the adoption of *this* proposal would transform a misspelling from a bug that the compiler catches to a bug that the compiler does not catch, I feel that my objection has been heard.

Thank you all,

- David

On Aug 10, 2017, at 1:51 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

Right. The objection raised is applicable to the overriding of any default implementation. However. _this_ proposal under review is about the synthesis of a default implementation, and we shouldn’t try to invent new syntax to address an orthogonal issue—and only partially at that.
On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Yes, thanks! Here’s the full proposal for those interested: https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md

I think that if we want to deal with the issue of some mistake arising from conforming to Equatable and/or Hashable, it should be through that proposal, not something specific to Equatable and Hashable. This sort of issue should not count against this Equatable/Hashable proposal.

On Aug 10, 2017, at 3:39 PM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the moment.

Is this what you’re thinking of?
Introducing Role Keywords to Protocol Implementations by erica · Pull Request #724 · apple/swift-evolution · GitHub

-Chris

.

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more explicit.
_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

9

Yes, but to be clear, this is an objection that is equally applicable to
any change where a protocol requirement is given a default implementation.

Unless I’m mistaken, ordinarily, the addition of such a default
implementation isn’t even considered an API change and doesn’t require
Swift Evolution approval.

···

On Thu, Aug 10, 2017 at 16:41 David Ungar <dungar@apple.com> wrote:

As long as I've been clear that the adoption of *this* proposal would
transform a misspelling from a bug that the compiler catches to a bug that
the compiler does not catch, I feel that my objection has been heard.

Thank you all,

- David

On Aug 10, 2017, at 1:51 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Right. The objection raised is applicable to the overriding of any default
implementation. However. _this_ proposal under review is about the
synthesis of a default implementation, and we shouldn’t try to invent new
syntax to address an orthogonal issue—and only partially at that.
On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution < > swift-evolution@swift.org> wrote:

Yes, thanks! Here’s the full proposal for those interested:
https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md

I think that if we want to deal with the issue of some mistake arising
from conforming to Equatable and/or Hashable, it should be through that
proposal, not something specific to Equatable and Hashable. This sort of
issue should not count against this Equatable/Hashable proposal.

On Aug 10, 2017, at 3:39 PM, Chris Lattner <clattner@nondot.org> wrote:

On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution < >> swift-evolution@swift.org> wrote:

I could have sworn that this sort of issue came up on this list earlier
this year… Someone proposed a mechanism encompassing all protocols, not
just Equatable and Hashable, to handle the issue of mistakenly believing
you’re overriding a default implementation. Having trouble finding it at
the moment.

Is this what you’re thinking of?
Introducing Role Keywords to Protocol Implementations by erica · Pull Request #724 · apple/swift-evolution · GitHub

-Chris

.

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution < >> swift-evolution@swift.org> wrote:

If I understand it, merely adding Equatable or Hashable will cause the
compiler to synthesize requirements. This syntax opens up the possibility
for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but
misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance
to "HashValue", in order to distinguish the two cases: explicit supplying
the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps
some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones
do not.

Alternatively, it might be clearer, though more verbose to move the
signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of
possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more
explicit.
_______________________________________________
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

10

Sorry, I think I misunderstood your earlier email. I believe we are in agreement.

···

On Aug 10, 2017, at 5:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Yes, but to be clear, this is an objection that is equally applicable to any change where a protocol requirement is given a default implementation.

Unless I’m mistaken, ordinarily, the addition of such a default implementation isn’t even considered an API change and doesn’t require Swift Evolution approval.

On Thu, Aug 10, 2017 at 16:41 David Ungar <dungar@apple.com> wrote:
As long as I've been clear that the adoption of *this* proposal would transform a misspelling from a bug that the compiler catches to a bug that the compiler does not catch, I feel that my objection has been heard.

Thank you all,

- David

On Aug 10, 2017, at 1:51 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Right. The objection raised is applicable to the overriding of any default implementation. However. _this_ proposal under review is about the synthesis of a default implementation, and we shouldn’t try to invent new syntax to address an orthogonal issue—and only partially at that.
On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

Yes, thanks! Here’s the full proposal for those interested: https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md

I think that if we want to deal with the issue of some mistake arising from conforming to Equatable and/or Hashable, it should be through that proposal, not something specific to Equatable and Hashable. This sort of issue should not count against this Equatable/Hashable proposal.

On Aug 10, 2017, at 3:39 PM, Chris Lattner <clattner@nondot.org> wrote:

On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the moment.

Is this what you’re thinking of?
Introducing Role Keywords to Protocol Implementations by erica · Pull Request #724 · apple/swift-evolution · GitHub

-Chris

.

On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <swift-evolution@swift.org> wrote:

If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling inside:

struct Snort: Hashable {
synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more explicit.
_______________________________________________
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