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

[Chris Lattner]

On Apr 20, 2016, at 12:31 PM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
> 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.

I completely agree, I think it makes sense to convert from unlabeled to labeled (or back) but not from “labeled" to "differently labeled”.

> 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?

I don’t think this follows, since operator parameters are always unlabeled.  I suspect we don’t reject it, but I’d be in favor of rejecting:

func +(lhs xyz: Int, rhs abc: Int) -> Int { }

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160420/abd66f6f/attachment.html>