Single-element labeled tuples?

Evolution Discussion
19

I'm also keen to see this feature, for both the @discardableResult case, and tuple values which are to be extended in the future.

Rather than restore the feature exactly as it was, I'd advocate keeping single-element tuples distinct from the raw type.

This would prevent this questionable feature: value.0.0.0.0; and presumably eliminate a source of compiler bugs.

To enumerate the possibilities:

//disabled - no `anyValue.0`
let tuple = 1 //clearly no intent to cast
let tuple = (1) //collides with regular brackets
let tuple = 1.0 //I don't even…

//allowed (?)
let i: Int = tuple //1, 2b
let tuple = 1 as (label: Int) //1, 2a
let tuple: (label: Int) = 1 //1, 2a
let tuple = (label: 1) //1, 2(a|b|ab)
//allowed (3)
let i: Int = tuple.label
func tupleReturning() -> (label: Int) {return 1}
func tupleReturning() -> (label: Int) {return (label: 1)}

  1. Allow all use cases, and simply disable the equivalence to the raw type (which is out of the question at this stage anyway).

  2. Re-enable single-element tuples as a separate type, with one/both restrictions:
    a. require accessing .label to convert (label: Int) to Int
    b. require (label: 1), by disabling conversion through type inteference.

  3. Re-enable only the last set of use-cases, or a subset with restrictions a/b, and restrict construction of single-element tuples to @discardableResult functions. The more conservative, but restrictive, approach.

Personally, I'm a fan of 2a, as it works nicely with use in discardable functions, and isn't overly restrictive.

3 Likes