Pitch: User-defined tuple conformances

[wadetregaskis]

Also, tangentially, if you try to force the creation of a single-element tuple by naming the contained element, e.g.:

func foo() -> (result: String) {
    return ("hello!")
}

…the resulting compiler error is a bit misleading, as it implies you can have single-element tuples, just not with named elements.

Cannot create a single-element tuple with an element label

(with a fixit to just remove the name, but not the misleading parenthesis)

Reinforcing my point that single-element tuples, or rather Swift's aversion to them, is already odd. (I'm not critiquing it, just noting - I suspect there's an upside to disallowing them, such as removing confusion between tuple declarations and mere scoping, both of which use parenthesis… although they could be distinguishable by requiring single-element tuples to have a trailing comma)

[Slava_Pestov]

@wadetregaskis

Though a more interesting question is whether (123).foo() should work. I think it should in order to be logically consistent, but I suspect it currently doesn't.

The current behavior is consistent, in that the parentheses are just grouping and not tuple formation -- so (123) has the exact same type as 123, which is not a tuple type. All of the funny behaviors of tuples immediately follow from this syntactic overlap (and the subsequent decision to disallow one-element tuples instead of having a special (x,) or (_: x) syntax or whatever that has a distinct type from x).

[ksluder (Kyle Sluder)]

There’s some very informative historical discussion in this pitch for single-element tuples from last year.

[Joe_Groff]

@Slava_Pestov

We could then say that members of tuple extensions are visible on all types, with non-tuple types just forming a one-element pack substitution for the call. But now namespace pollution becomes an issue, because you're just adding members to this single global namespace. It's just a can of worms that is not worth opening, in my opinion.

For the sake of argument, another alternative would be to say that tuple members are suppressed from being looked up on types that appear to be scalar. We had the problem you describe with the .0 member back in the Swift 0.x days, where it would be present on every type since every type is a single-element tuple of itself, acting like the identity member because the first element of a 1-tuple is the entire value. Now .0 is only resolvable when a type is visibly a tuple in context.

[dmt (Dima Galimzianov)]

Is there a rationale somewhere to read about why a single-element tuple must be identical to the element at all?

[ksluder (Kyle Sluder)]

Joe provides that in the form of a counter-argument in the above linked pitch thread.

[beccadax (Becca Royal-Gordon)]

@hborla

Personally, I think this pitch should stick to the tuple conformances already reviewed and accepted in SE-0283

This is a good justification to draw the line where you’ve drawn it.

[Morten_Bek_Ditlevsen]

I hope that it is ok that I bump this thread.
I was just curious about the state of the pitch. The possibilities it brings are really, really cool!

[Slava_Pestov]

Not much progress since the pitch sadly. The current state of the implementation is that the tuple conformance mechanism is already used for Copyable and Sendable tuples, and user-defined conformances make it as far as SILGen. The IRGen and runtime component still need to be implemented. If anyone wants to jump in I’d be happy to help figure it out.

[tera]

Will this be possible:

protocol P { func foo() }

extension (Int, String) : P {
    func foo() { /*...*/ }
}

(1, "hello").foo()

or what syntax will it be to express the above?

[tera]

Or simply:

func (Int, String).foo() { }

to have the "declaration site closely resembling the use site".

This if there's no need to state the protocol conformance.

I remember seeing the idea some time ago on this forum of making this form:

func T.foo() {}

an equivalent short hand notation of a longer form:

extension T {
	func foo() {}
}

IIRC that idea (can't find the thread right now) got quite a few positive replies but wasn't explored any further.

[Slava_Pestov]

@tera

Will this be possible:

protocol P { func foo() }

extension (Int, String) : P {
    func foo() { /*...*/ }
}

(1, "hello").foo()

or what syntax will it be to express the above?

The pitch only allows for (repeat each T) to conform to P where T: P, but with a bit of work we could also support more general tuple conformances.

A tuple conformance is essentially like an extension of a variadic nominal type:

struct FakeTuple<repeat each T> {}
extension FakeTuple ...

It's not supported right now, but we want this to work for parameter packs in general:

extension FakeTuple where (repeat each T) == (Int, String) {...}

So once that's worked out, your tuple conformance falls out immediately.

We have to be careful if we generalize this to avoid logical inconsistencies with one-element tuples; because a tuple conformance is just like the FakeTuple above, except that FakeTuple<T> is actually just T when T is a scalar type. We don’t want to back door a mechanism to make an arbitrary type conform to P because it was a one-element tuple before substitution.

You also wouldn’t be able to define two distinct tuple conformances to the same protocol, even with distinct requirements, because this would violate the restriction on overlapping conformances, just as if you tried the same with FakeTuple.

Also while it doesn’t create theoretical difficulties I’d prefer if we draw the line at adding arbitrary members to tuple types, and limit this to protocol conformances only. Otherwise overload resolution gets more complicated.

[fclout]

In that world, what's the rule for who's allowed to create tuple conformances to a protocol? For named types, we say it must be the module that either declares the type or declares the protocol. How does that work with tuples? Nobody owns a tuple type declaration.

[Joe_Groff]

The structural types notionally belong to the standard library, so only the standard library can non-@retroactive-ly define conformances for standard library protocols, and only the protocol's home module can non-@retroactive-ly define tuple conformances for a protocol outside of the standard library.

[Slava_Pestov]

Yeah, basically the author of a protocol gets to decide if tuples conform or not, and nobody else.

[George]

Is there a way to take this on a test drive in an available toolchain? I tried

      swiftSettings: [
        .enableUpcomingFeature("TupleConformances")
      ]
      swiftSettings: [
        .enableExperimentalFeature("TupleConformances")
      ]

in Xcode 16.1 beta 1 and neither seems to get the following code to work:

public protocol TestProtocol {
  
}

extension Tuple: TestProtocol where repeat each Element: TestProtocol {
  
}

extension <each T> (repeat each Element): TestProtocol where repeat each Element: TestProtocol {
  
}

[Slava_Pestov]

@George

Is there a way to take this on a test drive in an available toolchain?

Unfortunately it's not fully implemented:

1. There's no IRGen or runtime support. I had some experimental code a while ago to stub out enough in IRGen to get it working, but this approach didn't backward deploy at all, requiring a runtime change, and it would be nice if we could get the stdlib tuple conformances to backward deploy, at least when you don't use dynamic casts.
2. Also, non-static methods in tuple conformances that actually pass a tuple as the self value hit some existing SILGen bugs with parameter packs, so don't get past type checking.

@George

in Xcode 16.1 beta 1 and neither seems to get the following code to work:

The only syntax that works is extension Tuple,but you need to actually declare typealias Tuple<each Element> = (repeat each Element). It won't get far though, as per the above.

[George]

Thanks for the update. Been playing with parameter packs recently and this would be a very welcome improvement!