[swift-evolution] [Discussion] Enforce argument labels on tuples

[David Owens II]

This is similar to another concern I raised with functions and being able to essentially erase the function argument names and apply two different named parameters just because their types match.

It seems reasonable to me that you can go from (x: Int, y: Int) => (Int, Int). However, going from (x: Int, y: Int) => (a: Int, b: Int) feels somewhat odd. Yes, the types can obviously slot in there fine, but how much importance do the labels for the types bring to the table?

Similarly, should this (Int, Int) => (x: Int, y: Int) be allowed through an implicit means? If so, then it's really just an intermediate step for (x: Int, y: Int) => (a: Int, b: Int) working.

So what matters more, type signatures or label names?

Here's an example:

typealias Functor = (left: Int, right: Int) -> Int

func hi(x: Int, y: Int, fn: Functor) -> Int {
    return fn(left: x, right: y)
}

hi(1, y: 2, fn: +)
hi(1, y: 2, fn: *)

If we say that the parameter names are indeed vital, then the above code cannot work as the operators that match the type signature are defined as: 

public func +(lhs: Int, rhs: Int) -> Int

Obviously, given a name to the parameter brings clarity and can be self documenting, but if we want the above to work while making names just as vital as the type signature, then we need to declare `Functor` as such:

typealias Functor = (_ left: Int, _ right: Int) -> Int

However, that's not even legal code today, and even if it were, is that really better?

So I'm mixed on the idea. I think the idea that type coercions happening for matching type signatures is very powerful, and this just happens to be one of the example manifestations of that.

-David

> On Apr 20, 2016, at 6:23 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I would like to discuss about the following topic.
> 
> Wouldn't it be better to enforce argument labels on tuples types, if the tuple type defines them?
> 
> ```swift
> 
> func foo(tuple: (a: Int, b: Int)) { /* do something */ }
> 
> let test1 = (10, 100)
> let test2: (a: Int, c: Int) = test
> let test3: (Int, Int) = test2
> 
> foo(test1)
> foo(test3)
> 
> /*
> cannot convert value of type '(a: Int, c: Int)' 
> to expected argument type '(a: Int, b: Int)'
> */
> foo(test2) 
> 
> ```
> 
> Function `foo` awaits a tuple of type `(a: Int, b: Int)` but `test1` and `test3` are both just of type `(Int, Int)`.
> As expected `test2` will raise an error because it has indeed a wrong type `(a: Int, c: Int)`.
> 
> I'd suggest to enforce argument labeling on tuple types for better readability, because wasn't it the idea behind labels inside tuples?
> 
> `foo(test1)` should raise an error `cannot convert value of type '(Int, Int)' to expected argument type '(a: Int, b: Int)'` as long as `test1` is not written like `let test1 = (a: 10, b: 100)` or `let test1: (a: Int, b: Int) = (a: 10, b: 100)`
> 
> This will impact current codebase if you used labels but provided tuples without labels like the example above. The migrator could solve this by providing labels automatically to tuples where this error occurs.
> 
> I'm not good at writing proposals for the GitHub repository at all, so if the community likes this idea, I'd be glad to see some help for this little proposal.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160420/2677ab5f/attachment.html>