[swift-evolution] Partial list of open Swift 3 design topics

[Erica Sadun]

> On Jun 28, 2016, at 10:33 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jun 27, 2016, at 10:40 PM, Charlie Monroe <charlie at charliemonroe.net> wrote:
>> 
>> Oh, I see. The issue is then the following:
>> 
>> let x = f
>> x(1, 2) // Error: Missing argument labels 'a:b:' in call
>> 
>> let y: (Int, Int) -> () = f
>> f(1, 2) // OK
>> 
>> Which requires you to write x(a: 1, b: 2). I must admit, however, that I always liked this behavior…
> 
> Right, that’s the issue. The idea behind this is that it’s a simplification to the type system to eliminate argument labels from types, so we can eliminate some extra subtyping relationships (e.g., between function types with labels and ones without labels). Essentially, argument labels become part of the names of declarations (only!), which is consistent with our view that the names of functions/methods/initializers include all of the argument names.
> 
> 	- Doug

I'd really love if there were a simple way to bind labels to any tuple, where they can then be referred to by those labels in the current scope as well as by .0, .1, and by any other existing labels, so long as there's no syntactic confusion between labels. Labels would inherently simplify to positions with argument names as semantic sugar. Default values (now in fixed order) maintain position numbers even when excluded.

For example: myArray.enumerate.tupleBind(index:, value:).map({ do stuff with $0.index, $0.value })

Too impossible? Against Swift philosophy?

-- E