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
> <[email protected]> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
