> On Jun 28, 2016, at 10:33 AM, Douglas Gregor via swift-evolution
> <[email protected]> wrote:
>
>
>> On Jun 27, 2016, at 10:40 PM, Charlie Monroe <[email protected]>
>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
