Tuples conform to Equatable

Ah. I guess that. Thank you very much for detailed information!

It's really unfortunate because multi-argument functions don't work really. It was a mistake. There is solid algebra for type system design, and it should be followed. Most of the "features" people want can be made to work as sugar on top of this for direct calls. The sugar doesn't work when you move to closures which is just fine.

Anyhow as John McCall says, and i said myself, its unlikely the mistake can be fixed now, which unfortunately dead ends any further higher level extensions.

However it IS pertinent. If the labels on tuples are going away, the equality and total ordering and conversion to string and any other function with an invariant return type can be implemented by the user provided protocols support polymorphic recursion and tuples have a head/tail representation. This means it doesn't have to be special cased in the compiler, and can be defined in Swift instead, in the standard library or in user code.

About the process, I'd like to suggest that multiple threads be spawned so that each of the desired topics will be covered and so that the discussion of one topic won't drown out the discussion of others.

In light of the vision expressed by @Joe_Groff on behalf of the Core Team (as quoted, below), I'm suggesting threads along the following lines:

  • Built-in Protocol Conformance: Long-term Tradeoffs for Near-term Conformance
  • Built-in Protocol Conformance for Tuples: Proposal for Equatable, Hashable & Comparable
  • Built-in Protocol Conformance for Tuples: Codable Implementation Details
  • Built-in Protocol Conformance for Other Structural Types: Hashable
3 Likes

That looks to me like a good way to break out the threads.

Looks good to me. Who wants to start those threads?

It seems like it either should be @Alejandro or @Joe_Groff. Perhaps the honor should go to @Alejandro on account of the fantastic work done to push Equatable conformance forward, and thus prod these lines of discussion. I'd volunteer to spawn the threads, with liberal quoting from Joe's post to provide the substance for each thread, but I'm feeling a bit sheepish.

1 Like

It really doesn't seem unfortunate nor as a mistake to me, at least from what you've described here. Instead, maybe consider that Swift tried this approach and decided against it. Perhaps you have a different audience in mind with different needs than those addressed by the Swift language.

And by the way, welcome to the Swift Evolution community :smiley:

1 Like

I’ll be traveling today and this weekend, so I won’t be able provide a lot of substance, but I’d love to chime in with my thoughts. I wouldn’t mind if you simply created the trade off thread quoting some of the discussion here to start the discussion with. It'll probably be beneficial to start the trade off discussion first, then once I adjust the current proposal to include hashable and comparable, I can spawn a new proposal thread for those. The rest of the discussions can follow for more additions after we get the big three in for tuples first.

I will spawn a thread regarding the trade-off question, and populate it with an introduction summarizing some of the posts from this thread that speak to the trade-off question.

1 Like

I’d think that in-out parameters would then have to done like C does it, pass-by-value with a pointer. This could prevent pass-by-copy-in-and-out, or force all variables to be addressable by default, which could ban other optimizations.

Unfortunately, this behaves correctly. I'm going to leave the SR and add it to the list of reasons we need to remove tuple shuffles.

2 Likes

It's worth noting that tuple shuffles and labeled/unlabeled conversions are separable concerns from whether tuples conform to protocols. The distinctions between differently-labeled tuple types is maintained by the runtime type system, so they would all conform individually to Equatable or other protocols.

Terms of Service

Privacy Policy

Cookie Policy