[swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

[Vladimir.S]

On 04.07.2016 16:33, Anton Zhilin via swift-evolution wrote:
> How does this proposal agree with tuple labels? Compare:
>
> func find(array: [Int], value: Int) -> (index: Int, value: Int)
> let result = find(...)
> result.index  //=> 0
>
> func getHandler(for kind: EventKind) -> (event: Event, parent: Widget) -> ()
> let result = getHandler(...)
> result(event: ..., parent: ...)
>
> We are going to prohibit second without removing the first; how is that
> consistent?

I don't expect this will be changed, and expect this will work similar as 
for tuples, i.e. for me labels for arguments is just for declaration(for 
syntax), not for type of returned value: (Swift Ver. 3.0 (Jun 20, 2016))

func f() -> (index: Int, value: Int) { return (index: 1, value: 2) }

let result1 = f()
let result2 : (Int, Int) = f()

print(result1, result2) // (1, 2) (1, 2)
print(result1.index, result2.0) // 1 1
print(result1.dynamicType) // (Int, Int)
print(result1.dynamicType == result2.dynamicType) // true

typealias MyTuple = (x: Int, y: Int)

print(MyTuple.self == result1.dynamicType) // true

print("--------")

func getHandler(for kind: Int) -> (event: String, parent: String) -> () {
     return { event, parent in print(event, parent) }
}

var handler1 : (String, String) -> () = {_, _ in }
handler1 = getHandler(for: 0)
handler1("event1", "parent1")

let handler2 = getHandler(for: 0)
handler2(event: "event2", parent: "parent2")

print(handler1.dynamicType) // ((String, String)) -> ()
print(handler1.dynamicType == handler2.dynamicType) // true


func someFunc(name n: String, description d: String) {
     print("name/desc: ", n, d)
}

print(someFunc.dynamicType) // ((String, String)) -> ()

print(handler1.dynamicType == someFunc.dynamicType) // true


>
> 2016-07-04 14:17 GMT+03:00 Brent Royal-Gordon via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>
>     >       * What is your evaluation of the proposal?
>
>     I agree that the current situation is incoherent. If the type system
>     doesn't care about the labels, the labels probably shouldn't be in the
>     type.
>
>     In the long run, it must be possible to label the parameters of a
>     closure. But that labeling does not *necessarily* belong on the type;
>     it could go on the name:
>
>             // Old and busted
>             let completion: (records: [Record]?, error: Error?) -> Void
>             // New hotness
>             let completion(records:error:): ([Record]?, Error?) -> Void
>
>     And I don't think it would be terrible to remove the labels from the
>     type before we add them to the name.
>
>     On the other hand, we could go the other direction and make the labels
>     significant. Or—to address the `remove(from:)`/`add(to:)` critique—we
>     could perhaps make the *internal* names significant, while considering
>     the internal labels as part of the variable name. (Presumably both
>     `remove(from:)` and `add(to:)` would be of type `(collection:
>     WidgetCollection) -> Void`.)
>
>     Both options are sensible; the status quo is not. We should choose a
>     direction and start going that way.
>
>     >       * Is the problem being addressed significant enough to warrant
>     a change to Swift?
>
>     Yes. The type system is being a bit nonsensical here.
>
>     >       * Does this proposal fit well with the feel and direction of Swift?
>
>     Yes. Swift 3, breaking everything now, etc.
>
>     >       * If you have used other languages or libraries with a similar
>     feature, how do you feel that this proposal compares to those?
>
>     Can't really think of much that's comparable.
>
>     >       * How much effort did you put into your review? A glance, a
>     quick reading, or an in-depth study?
>
>     Quick reading.
>
>     --
>     Brent Royal-Gordon
>     Architechies
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>