# Make "tuple syntax" a shorthand for initializing a contextual type

**URL:** <https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740>\
**Category:** Pitches\
**Created:** [February 12, 2020, 1:02pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740 "2020-02-12T13:02:18Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jens](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jens/32/12903_2.png) [@Jens](https://forums.swift.org/u/Jens)\
**Post date:** [February 12, 2020, 1:02pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/1 "2020-02-12T13:02:18Z")

</div>

There's been a lot of talk about adding an `ExpressibleByTupleLiteral` on these forums (for example [1](https://forums.swift.org/t/expressiblebytupleliteral-instead-of-tuples-conforming-to-protocols/29626), [2](https://forums.swift.org/t/making-tuples-more-useful-with-expressiblebytupleliteral/11248), [3](https://forums.swift.org/t/implementing-expressiblebytupleliteral-how-hard/21169), [4](https://forums.swift.org/t/expressiblebytupleliteral-instead-of-tuples-conforming-to-protocols/29626), and [5](https://forums.swift.org/t/pitch-protocol-conformance-for-tuples-anonymous-structs/24207)).

And it seems like much of it has to do with this little annoyance:

```swift
Rect<Float>(origin: SIMD2<Float>(1, 2), size: SIMD2<Float>(3, 4))
Rect<Float>(origin: SIMD2<Float>.init(1, 2), size: SIMD2<Float>.init(3, 4))
Rect<Float>(origin: .init(1, 2), size: .init(3, 4)) // You accept this …
Rect<Float>(origin: .ini(1, 2), size: .ini(3, 4)) // … so …
Rect<Float>(origin: .in(1, 2), size: .in(3, 4)) // … why …
Rect<Float>(origin: .i(1, 2), size: .i(3, 4)) // … not …
Rect<Float>(origin: .(1, 2), size: .(3, 4)) // … just …
Rect<Float>(origin: (1, 2), size: (3, 4)) // … accept this too, please?

```

* * *

There are tons of `.init(…)`s in my (geometry-/graphics-) code, and the `.init`-part is doing _nothing_ for me as a human being, it's just meaningless noise. Perhaps the compiler could manage without all these `.init`s too?

```swift
foo(bounds: .init(origin: .init(1, 2), size: .init(3, 4)), barPoint: .init(5, 6))
foo(bounds: (origin: (1, 2), size: (3, 4)), barPoint: (5, 6)) // Ah!

```

* * *

So instead of adding an `ExpressibleByTupleLiteral` protocol, make "tuple syntax" (ie a naked argument list, `.init(…)` without the `.init`) a shorthand for initializing a contextual type, as explained by Joe Groff here:

> [@Implementing ExpressibleByTupleLiteral: how hard?](https://forums.swift.org/t/implementing-expressiblebytupleliteral-how-hard/21169/9):
>
> I think it'd be better to make tuple syntax a shorthand for initializing a contextual type (like `.init(...)` but without the `.init` ) than to introduce a protocol for making certain types able to use tuple syntax. I can see many benefits to this:
> 
> - It doesn't need any new fundamental type system features to support the full functionality of tuple syntax, including variable numbers of arguments, preservation of the individual element types, labels, etc., since these can all be expressed as initializer overloads.
> - It reduces the friction in migrating a tuple to a named type, if you outgrow the abilities of tuples.
> - It would make expressing large, well-typed literals generally more streamlined, since you wouldn't need `.init(...)` or `T(...)` prefixes that can be deduced from context.
> - Protocols need runtime support, and any new ones we add will be availability-gated by OS versions with new enough standard libraries to provide them. I think that indicates that protocol requirements are not a great idea for features that are intended primarily as compile-time syntactic conveniences.

I've read through these previous discussions but couldn't make out whether this change would be possible and if so worth its weight, so I wrote this pitch.

* * *

# In short:

Wherever this currently compiles:

`.init(…)`

so should this:

`(…)`

---

<div class="post-metadata">

**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\
**Post date:** [February 12, 2020, 1:59pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/2 "2020-02-12T13:59:23Z")

</div>

Tangential to what you're asking for, but worth noting: the SIMD types are already ExpressibleByArrayLiteral, so you can do

```swift
Rect<Float>(origin: [1,2], size: [3,4])

```

This isn't as tidy as what you want, but it already works with the language we have today.

As for the actual pitch, I think it's a great idea, and we mostly need someone to actually implement it in a PR. There are some policy questions to resolve, but they're best addressed with reference to an implementation.

---

<div class="post-metadata">

**Author:** ![cal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cal/32/35557_2.png) [@cal](https://forums.swift.org/u/cal)\
**Post date:** [February 12, 2020, 4:02pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/3 "2020-02-12T16:02:42Z")

</div>

One thought on this.

Current [grammar](https://docs.swift.org/swift-book/ReferenceManual/Expressions.html#ID394) for Implicit Member Expressions always start with a leading dot:

```swift
implicit-member-expression → .identifier

```

This leading dot is a valuable signal to the reader that this implicit behavior is being used.

```swift
// The reader has no indication that this is implicitly using some type's `init`
// and can easily mistake these arguments for `(Int, Int)` tuples.
Rect<Float>(origin: (1, 2), size: (3, 4))

// The reader knows that the arguments are some sort 
// of implicit expression on the type of the argument
Rect<Float>(origin: .(1, 2), size: .(3, 4))

```

---

<div class="post-metadata">

**Author:** ![AnotherUser](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anotheruser/32/14927_2.png) [@AnotherUser](https://forums.swift.org/u/AnotherUser)\
**Post date:** [February 12, 2020, 10:02pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/4 "2020-02-12T22:02:52Z")

</div>

I agree with @cal’s point. I’d at least like to be able to optn+click or cmd+click on some part of the expression in Xcode and see what exactly is being called. A leading dot has enough space I think (perhaps the minimum amount of space) to get a good click in, and sets this syntax apart from a regular tuple literal.

---

<div class="post-metadata">

**Author:** ![Jens](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jens/32/12903_2.png) [@Jens](https://forums.swift.org/u/Jens)\
**Post date:** [February 12, 2020, 10:31pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/5 "2020-02-12T22:31:19Z")

</div>

As @scanon mentioned above, we can currently write:

```swift
Rect<Float>(origin: [1,2], size: [3,4])

```

So the same arguments could be used against `ExpressibleByArrayLiteral`, ie: _The user can easily mistake these arguments for arrays, and cannot option click them._

* * *

I think we can trust programmers to use this shorthand (of dropping the `.init`) in situations where it makes sense, and I don't think leaving the dot would add more clarity than it adds noise:

`foo(bounds: .(origin: .(1, 2), size: .(3, 4)), barPoint: .(5, 6))`  
`foo(bounds: (origin: (1, 2), size: (3, 4)), barPoint: (5, 6))`

And, without the dots, you can still option-click the argument labels to see the types. Clicking on `bounds` shows you that it takes a `Rect<Float>`, and clicking on `origin`, `size` or `barPoint` lets you know they're all `SIMD2<Float>` (though I doubt those details are essential to understanding what the code is _really_ about.)

---

<div class="post-metadata">

**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\
**Post date:** [February 12, 2020, 10:43pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/6 "2020-02-12T22:43:54Z")

</div>

It would be nice in general for literals to be "jump to definition"-able. Cmd-clicking the brackets of an array/dictionary/tuple literal could take you to the initializer call that will perform the construction from the literal.

---

<div class="post-metadata">

**Author:** ![Jens](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jens/32/12903_2.png) [@Jens](https://forums.swift.org/u/Jens)\
**Post date:** [February 12, 2020, 10:49pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/7 "2020-02-12T22:49:42Z")

</div>

And option-clicking could tell you the contextual type.

---

<div class="post-metadata">

**Author:** ![cal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cal/32/35557_2.png) [@cal](https://forums.swift.org/u/cal)\
**Post date:** [February 12, 2020, 11:43pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/8 "2020-02-12T23:43:01Z")

</div>

> [@Jens](#):
>
> As @scanon mentioned above, we can currently write:
> 
> ```swift
> Rect<Float>(origin: [1,2], size: [3,4])
> 
> ```
> 
> So the same arguments could be used against `ExpressibleByArrayLiteral` , ie: _The user can easily mistake these arguments for arrays, and cannot option click them._

This is a great point.

---

<div class="post-metadata">

**Author:** ![GetSwifty](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/getswifty/32/39108_2.png) [@GetSwifty](https://forums.swift.org/u/GetSwifty)\
**Post date:** [February 13, 2020, 12:40am UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/9 "2020-02-13T00:40:34Z")

</div>

```swift
//A
Rect<Float>(origin: (1, 2), size: (3, 4))
//B
Rect<Float>(origin: .init(1, 2), size: .init(3, 4))

```

Although I like cleanliness of A, IMO it meaningfully sacrifices clarity for brevity compared to `B` because you lose any indication you're passing Types instead of naked Values. In Domain-specific code where this is done often and a Rect is a well understand concept, that's fine! In a more general context it's not. That's why you can create an extension with an initializer with whatever you want:

```swift
extension Rect {
    init(origin: (_ x: T, _ y: T), size: (_ width: T, _ height: T)) {
    // implementation
    }
}
// Now your ideal works!
let myRect: = Rect<Float>(origin: (0, 0), size: (320, 200))

```

But that's really a question of API design, not language features.

What this is asking for not only reverses the [removal of implicit splat](https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md), but also adds implicit initialization. That's an amount of magic that feels foreign in Swift and would probably add a good amount of Type checker headaches as well. On top of that, how do you implicitly choose between initializers with the same Types, but different labels?

```swift
init(width: Float, height: Float) 
//vs 
init(height: Float, width: Float)

```

What happens when there was only one, but then another was added? Do all the implicit conversions break and make you use the initializer directly? What if one is deleted and replaced by the other? Now you have a _silent_ failure. 😬

I definitely want Tuples to have more utility, but the "right" way is for a Type to define _how_ they can be converted from a Tuple. Not doing it without their permission. Till then, extensions are your friend.

---

<div class="post-metadata">

**Author:** ![AnotherUser](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anotheruser/32/14927_2.png) [@AnotherUser](https://forums.swift.org/u/AnotherUser)\
**Post date:** [February 13, 2020, 2:10am UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/10 "2020-02-13T02:10:42Z")

</div>

> [@Joe\_Groff](#):
>
> It would be nice in general for literals to be "jump to definition"-able. Cmd-clicking the brackets of an array/dictionary/tuple literal could take you to the initializer call that will perform the construction from the literal.

I agree with @GetSwifty's points. Extensions would work well for us here. Since we're in the discussion though, I wanna ditto @Joe_Groff's comment. Heck, it'd be nice for newbies ~~like me~~ to be able to option click language keywords like `let` or `defer` to see how they work! I know there's documentation on that, but I just think it'd be cool if our IDE could teach us a little about the language.

I notice that a lot of operators now let us option click, as of Xcode 11 I believe. That is nice. A small thing, but nice.

---

<div class="post-metadata">

**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\
**Post date:** [February 13, 2020, 3:28am UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/11 "2020-02-13T03:28:20Z")

</div>

> [@GetSwifty](#):
>
> I definitely want Tuples to have more utility, but the "right" way is for a Type to define _how_ they can be converted from a Tuple. Not doing it without their permission.

A good question to ask here is, why and how would a type's "how can I be instantiated from a tuple" be different from how it could be instantiated generally? I can think of at least one answer, which is the single-argument initializer case. `Foo(x)` makes sense to build a `Foo` from `x`, but `(x)` by itself would definitely be surprising if it could hide a type conversion.

---

<div class="post-metadata">

**Author:** ![typesanitizer](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/typesanitizer/32/8661_2.png) [@typesanitizer](https://forums.swift.org/u/typesanitizer)\
**Post date:** [February 13, 2020, 3:38am UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/12 "2020-02-13T03:38:59Z")

</div>

For this particular example, if you use something like

```swift
typealias V2 = SIMD2<Float>

```

that makes the thing pretty nice to read/write IMO:

```swift
Rect<Float>(origin: V2(1, 2), size: V2(3, 4))

```

---

<div class="post-metadata">

**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\
**Post date:** [February 13, 2020, 9:10am UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/13 "2020-02-13T09:10:22Z")

</div>

> [@GetSwifty](#):
>
> On top of that, how do you implicitly choose between initializers with the same Types, but different labels?
> 
> ```swift
> init(width: Float, height: Float) 
> //vs 
> init(height: Float, width: Float)
> 
> ```
> 
> What happens when there was only one, but then another was added? Do all the implicit conversions break and make you use the initializer directly? What if one is deleted and replaced by the other? Now you have a _silent_ failure. 😬

The labels are part of the call-site, non?

If I understand this correctly, this isn't asking to allow types to be instantiated from tuples, but to allow tuple-like syntax for contextual type instantiation. That is, simply removing the `.init` from call-site but keep the labels, order and everything else the same.

---

<div class="post-metadata">

**Author:** ![Jens](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jens/32/12903_2.png) [@Jens](https://forums.swift.org/u/Jens)\
**Post date:** [February 13, 2020, 9:22am UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/14 "2020-02-13T09:22:12Z")

</div>

> [@GetSwifty](#):
>
> What this is asking for not only reverses the [removal of implicit splat](https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md), but also adds implicit initialization.

No (unless I'm missing something). See @sveinhal's answer above.

For example, let's say we can currently write this:  
`foo(bar: .init(a: 12, b: true))`  
then with this pitch implemented, the following would be equivalent (via sugar):  
`foo(bar: (a: 12, b: true))`

> [@GetSwifty](#):
>
> On top of that, how do you implicitly choose between initializers with the same Types, but different labels?
> 
> ```swift
> init(width: Float, height: Float) 
> //vs 
> init(height: Float, width: Float)
> 
> ```
> 
> What happens when there was only one, but then another was added? Do all the implicit conversions break and make you use the initializer directly? What if one is deleted and replaced by the other? Now you have a _silent_ failure. 😬

I'm not sure what you mean here. It would always be using the initializer directly, the same that is currently used when writing `.init(…)`, ie  
`.init(width: height: )` or  
`.init(height: width: )`.

The pitch is this:

> [@Jens](#):
>
> Wherever this currently compiles:
> 
> `.init(…)`
> 
> so should this:
> 
> `(…)`

So using your particular example, we can (in current Swift) write:

```swift
foo.bar(size: .init(width: 12, height: 34))
foo.bar(size: .init(height: 56, width: 78))

```

and with this pitch implemented, we'd be allowed to skip the `.init`-parts, and write:

```swift
foo.bar(size: (width: 12, height: 34))
foo.bar(size: (height: 56, width: 78))

```

Which would just be sugar for the above.

* * *

Perhaps you mean what would happen if someone (for some unknown reason) added a tuple-taking initializer? Then that initializer would be called (in current Swift) like this:

```swift
foo.bar(size: .init((width: 12, height: 34))) // or without labels:
foo.bar(size: .init((12, 34)))

```

which with the pitch implemented could be shortened to:

```swift
foo.bar(size: ((width: 12, height: 34)))
foo.bar(size: ((12, 34)))

```

(Note that it changes nothing, the double parens still make it unambiguous.)

Or what would happen if there was a `foo.bar(size tupleSize: (Int, Int))`? Then there would be an ambiguity error I guess, but no one would have a reason to write that tuple-variant of the method anyway.

So, ideally, this would have (next to) nothing to do with tuples, although I wouldn't be surprised if trying to implement it would open up a can of parenthesis- / tuple expression-related worms. But as I have no insight into the compiler, others would have to say whether something like that would be a show stopper or not.

* * *

* * *

> [@GetSwifty](#):
>
> ```swift
> //A
> Rect<Float>(origin: (1, 2), size: (3, 4))
> //B
> Rect<Float>(origin: .init(1, 2), size: .init(3, 4))
> 
> ```
> 
> Although I like cleanliness of A, IMO it meaningfully sacrifices clarity for brevity compared to `B` because you lose any indication you're passing Types instead of naked Values.

Clarity is _all about_ selectively _leaving out_ information. If all information (no matter how detailed, obvious, well-known, context-given, etc) is spelled out everywhere, the important stuff gets lost in the noise of the less important.

We are now using `.init(…)` where we see it fit, because the contextual type is well-known or less important than whatever the `.init`- parts of those `.init(…)`s are _still_ stealing attention from. The `.init`-parts are just the last bit of noise that the _compiler_ forces on us.

This pitch is about letting us skip the `.init`-part of the `.init(…)`s we've already chosen to write and accept in code review. And (as explained above) it's not hard to look up the types, should it be necessary.

> [@GetSwifty](#):
>
> In Domain-specific code where this is done often and a Rect is a well understand concept, that's fine!

Yes, just as with all other shorthands in Swift (eg type inference), this shorthand would be optional and could both clarify and obscure, depending on how, where and why it is used.

Clarity in code (or communication in general) depends on _us_ being able to _focus_ on what's important. This is impossible without leaving out tons of contextually less important stuff. Programming and communication is about abstraction, enabling ourselves to concentrate on "higher" levels by hiding "lower" levels of abstraction. And what is relevant (higher level) in one situation can be irrelevant (lower level) in another. Abstraction (hiding) is all we do when writing code, we bundle up a lot of details behind nice types and methods etc, but that kind of abstraction can only take us so far, because (depending on the language) we can't continue abstracting beyond the limits of syntax.

I love that Swift acknowledges this, and gives the _programmer / code reviewer_ some ability to decide syntax-wise what information is best kept in or out of some given piece of code.

* * *

* * *

> [@GetSwifty](#):
>
> ```swift
> extension Rect {
> init(origin: (_ x: T, _ y: T), size: (_ width: T, _ height: T)) {
> // implementation
> }
> }
> // Now your ideal works!
> let myRect: = Rect<Float>(origin: (0, 0), size: (320, 200))
> 
> ```
> 
> But that's really a question of API design, not language features.

> [@typesanitizer](#):
>
> For this particular example, if you use something like
> 
> ```swift
> typealias V2 = SIMD2<Float>
> 
> ```

Sure, we could add typealiases like `V2F = SIMD2<Float>`, `V4F = SIMD4<Float>`, `RF = Rect<Float>`, ... and/or we could add tuple-arg-variants of each and every frequently used initializer and method (which in my case would be something like 100+ tuple-arg-variants). There are all sorts of ways to piece together alternative and to my mind more cumbersome solutions.  
: )

I will not continue "defending" the idea of this pitch, since my English skills prevent me from doing so effectively and I've already started repeating myself. It'd be nice if someone liked to have a go at implementing it in a PR so we could try it out in practice!

---

<div class="post-metadata">

**Author:** ![GreatApe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/greatape/32/2640_2.png) [@GreatApe](https://forums.swift.org/u/GreatApe)\
**Post date:** [February 13, 2020, 12:01pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/16 "2020-02-13T12:01:52Z")

</div>

I’m not sure I understand this argument. There are already plenty of places where literals don’t reveal, in themselves, what they will be interpreted as. Doubles without decimals look like ints, sets look like arrays etc, so I don’t think this is a problem at all. Especially in your example, where it is 100% clear how the tuples will be interpreted, anyone can easily see that 1 will be x, 2 will be y etc, so there should be no potential for confusion at all. And this would be true in general, since the tuples would always have the same arguments in the same order.

---

<div class="post-metadata">

**Author:** ![GetSwifty](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/getswifty/32/39108_2.png) [@GetSwifty](https://forums.swift.org/u/GetSwifty)\
**Post date:** [February 13, 2020, 2:29pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/17 "2020-02-13T14:29:53Z")

</div>

> [@Jens](#):
>
> No (unless I'm missing something). See @sveinhal's answer above.
> 
> For example, let's say we can currently write this:  
> `foo(bar: .init(a: 12, b: true))`  
> then with this pitch implemented, the following would be equivalent (via sugar):  
> `foo(bar: (a: 12, b: true))`

Ok here's (at least) my confusion here, same with @sveinhal. Tuples no longer have named items. So to use tuples it would also require adding those back. Seems like really what you're wanting is simply omitting `init` for contextual types. That looks like Tuple _syntax_, but would still need to be an argument list for the same reason implicit splat was removed.

I think that still has the clarity issue of one thing looking like another. In some contexts that's ok, but IMO that should be left up to the API designers. And again, if you find yourself repeating yourself enough to be annoyed, there's already a very simple solution: add an extension.

You've argued your point well from a specific usage perspective, but IMO it's not something that should be in the language.

---

<div class="post-metadata">

**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\
**Post date:** [February 13, 2020, 4:10pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/18 "2020-02-13T16:10:26Z")

</div>

I repeat: This has _nothing_ to do with tuples.

- You can already remove the `.init` and place a "naked" argument list after a type name to instantiate call its constructor.
- You can also already remove the type name, when the type can be inferred. But then you have to add the `.init` back in.

This proposal suggest adding bare/naked argument lists whenever the type can be inferred. Tuples is only mentioned because this is an alternative to a previous idea about `ExpressibleByTupleLiteral`, and has similar-ish syntax.

This is a much simpler proposal though. Don't think of it as tuples.

---

<div class="post-metadata">

**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\
**Post date:** [February 13, 2020, 4:14pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/19 "2020-02-13T16:14:56Z")

</div>

> [@GetSwifty](#):
>
> And again, if you find yourself repeating yourself enough to be annoyed, there's already a very simple solution: add an extension.

What if you find yourself repeating this extension often enough to be annoyed?  
Then the solution is either meta programming or language support, non?

That's the gist of this proposal. I think it fits nicely.

---

<div class="post-metadata">

**Author:** ![GetSwifty](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/getswifty/32/39108_2.png) [@GetSwifty](https://forums.swift.org/u/GetSwifty)\
**Post date:** [February 13, 2020, 4:47pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/20 "2020-02-13T16:47:15Z")

</div>

> [@sveinhal](#):
>
> What if you find yourself repeating this extension often enough to be annoyed?  
> Then the solution is either meta programming or language support, non?

**Or** put it in a package for easier reuse **or** add to the library being used. There are plenty of options less-nuclear than requiring that something be added to the language.

I'm _less_ against this when all mention of Tuples are removed, but it still seems like an overreach of cleanliness.

From a more opinionated POV, this is the kind of feature that could be easily abused. In certain environments where the same Type is created/used everywhere the desired syntax is fine but even if this was added, my advice would be to use it sparingly-if-ever. For my day-to-day (mostly iOS) work, there are _very few_ places where I would see this as an improvement for code readability.

Basically, if we're risking sacrificing code clarity everywhere it should be for something more than saving 5 characters.

---

<div class="post-metadata">

**Author:** ![mattpolzin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattpolzin/32/6041_2.png) [@mattpolzin](https://forums.swift.org/u/mattpolzin)\
**Post date:** [February 13, 2020, 4:52pm UTC](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740/21 "2020-02-13T16:52:25Z")

</div>

> [@GetSwifty](#):
>
> if we're risking sacrificing code clarity everywhere it should be for something more than saving 5 characters.

This is the crux of it, though. Going from `Foo(...)` to `.init(...)` (the status quo) already loses clarity for brevity sake. The developer already must make a judgement call. The question is whether it is ever cleaner-enough to drop the `.init` as well to make it worthwhile. I’ve written enough large declarative definitions to feel positively about the additional brevity. It would make some of my code easier to read.

[Next page](https://forums.swift.org/t/make-tuple-syntax-a-shorthand-for-initializing-a-contextual-type/33740.md?page=2)