[Discussion] Enforce argument labels on tuples

[DevAndArtist]

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?

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

[owensd]

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

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

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

···

On Apr 20, 2016, at 12:31 PM, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

[Haravikk3]

I’m not sure about a general rule, but I think that labels should be required for associated types and type aliases. I can’t check right now if this changed in Swift 3, but in earlier version Dictionary for example has the associated type Element which is a tuple of (Key, Value). While using this via .0 and .1 is fine generally, I’d much rather the parameters were named key and value for absolute clarity, and think that this the way to go with these. For ad-hoc tuples it doesn’t matter so much, but yeah, the rest of the time I’d prefer to be clear.

While it may be annoying in cases where names don’t match, I think that’s fine too, as it forces us to be explicit about what’s happening, as it may not always be clear to someone new to maintaining the code. There could perhaps be a simpler syntax for mapping tuples, or an attribute/compiler directive to ignore the mismatch anywhere it occurs?

···

On 20 Apr 2016, at 14:23, Adrian Zubarev via swift-evolution <swift-evolution@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?

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tino]

I think it's good that the labels aren't enforced:
This would sacrifice flexibility, and force us to write unnecessary boilerplate to "translate" labels (one library might use (height, width), and another (h, w) to express the same concept…)

But: Objective-C had no tuples, so a final decision shouldn't happen until there is an agreement on best-practices for them...

[Austin]

+1 to Tino's concern. This seems like something better suited for a formal newtype style feature.

Austin

···

On Apr 20, 2016, at 10:47 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

I think it's good that the labels aren't enforced:
This would sacrifice flexibility, and force us to write unnecessary boilerplate to "translate" labels (one library might use (height, width), and another (h, w) to express the same concept…)

But: Objective-C had no tuples, so a final decision shouldn't happen until there is an agreement on best-practices for them...
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[David_Sweeris]

What about enforcing the argument labels, but then adding a “@autolabel” or something in code where the current behavior is desired?

- Dave Sweeris

···

On Apr 20, 2016, at 12:47 PM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

I think it's good that the labels aren't enforced:
This would sacrifice flexibility, and force us to write unnecessary boilerplate to "translate" labels (one library might use (height, width), and another (h, w) to express the same concept…)

But: Objective-C had no tuples, so a final decision shouldn't happen until there is an agreement on best-practices for them...
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[DevAndArtist]

That’s why I’d like to discuss this topic and hear all your feedback.

Do you think it might be possible to add some optional extra flag to the language to enforce argument labeling. Not only for tuples as I started the discussion with but also for argument labels on blocks/closures?

@require_argument_label
func foo(tuple: (a: Int, b: Int)) { /* do some work */ }

// this will only work with

let test1 = (a: 1, b: 2)
foo(test1)

func foo(block: (boo: Int) -> Void) { /* pass boo to block */ }

foo() { boo in // do is enforced here
	/* do some work*/
}

// or

foo() { (boo: Int) -> Void in
	/* do some work*/
}

An extra flag won’t break any codebase and as an addition will allow some good looking syntax at some places.

···

--
Adrian Zubarev

Am 20. April 2016 bei 19:47:03, Tino Heth (2th@gmx.de) schrieb:

I think it's good that the labels aren't enforced:
This would sacrifice flexibility, and force us to write unnecessary boilerplate to "translate" labels (one library might use (height, width), and another (h, w) to express the same concept…)

But: Objective-C had no tuples, so a final decision shouldn't happen until there is an agreement on best-practices for them...

[DevAndArtist]

@Austin I wasn’t talking about the tuple splat feature here.

In my case I was trying to simplify the example of a function that awaits an actual tuple of a specific type, which in my case also (should) have argument labels.

func foo(tuple: (a: Int, b: Int)) {}

let tuple = (10, 42)
foo(tuple)

// this is not the same as 

func boo(a: Int, b: Int) {}
boo(42, b: 17)

let x = (1, b: 2)
boo(x) // which will be removed in Swift 3

···

--
Adrian Zubarev

Am 20. April 2016 bei 20:11:01, Haravikk (swift-evolution@haravikk.me) schrieb:

organization's policy

[owensd]

So maybe I think about this incorrectly, but I always think of any parameter without an explicit label to have one that is equal to the parameter name. So these two functions signatures would be equivalent:

func sum1(lhs: Int, rhs: Int) -> Int
func sum2(lhs lhs: Int, rhs rhs: Int) -> Int

It’s only when you explicit “erase” the label where there is none:

func sum(_ lhs: Int, _ rhs: Int) -> Int

So back to the example above, it’s still somewhat odd that all of these are valid:

hi(1, y: 2, fn: sum1)
hi(1, y: 2, fn: sum2)
hi(1, y: 2, fn: sum) // makes the most sense, no label to labeled promotion

But if we did reject the differently labeled version, that would mean that we would need to declare the `Functor` above as:

typealias Functor = (Int, Int) -> Int

Is that better? I’m not terribly convinced that it is.

If `Functor` keeps the labels, I suspect it would just lead to additional boiler-plate code that would look like:

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

hi(1, y: 2, fn: { left, right in sum1(lhs: left, rhs: right) })

While it does seem technically correct, is that really the kind of code we want in Swift?

-David

···

On Apr 20, 2016, at 4:47 PM, Chris Lattner <clattner@apple.com> wrote:

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

[William_Dillon2]

Do you think it might be possible to add some optional extra flag to the language to enforce argument labeling. Not only for tuples as I started the discussion with but also for argument labels on blocks/closures?

That seems fairly heavy-handed, also.

This feels like the kind of thing that should be enforced by an organization's policy not by the language, IMHO.

- Will

[Austin]

The tuple splat feature you mention below ("foo(test1)", where test1 is a tuple ) is going away in Swift 3, as is the entire idea of modeling a function's list of formal parameters as a named tuple.

Aside from that, my personal opinion is that forcing a closure to take certain argument names is way too onerous a requirement for very little benefit. It would, for example, disqualify the use of the $x wildcards or the use of local argument names which more precisely represent the semantics of the closure. Function signatures are already very complicated, so I think any new attributes or flags should really have a strong argument to justify their inclusion.

Austin

···

On Apr 20, 2016, at 10:59 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

That’s why I’d like to discuss this topic and hear all your feedback.

Do you think it might be possible to add some optional extra flag to the language to enforce argument labeling. Not only for tuples as I started the discussion with but also for argument labels on blocks/closures?

@require_argument_label
func foo(tuple: (a: Int, b: Int)) { /* do some work */ }

// this will only work with

let test1 = (a: 1, b: 2)
foo(test1)

func foo(block: (boo: Int) -> Void) { /* pass boo to block */ }

foo() { boo in // do is enforced here
	/* do some work*/
}

// or

foo() { (boo: Int) -> Void in
	/* do some work*/
}

An extra flag won’t break any codebase and as an addition will allow some good looking syntax at some places.

--
Adrian Zubarev

Am 20. April 2016 bei 19:47:03, Tino Heth (2th@gmx.de <mailto:2th@gmx.de>) schrieb:

I think it's good that the labels aren't enforced:
This would sacrifice flexibility, and force us to write unnecessary boilerplate to "translate" labels (one library might use (height, width), and another (h, w) to express the same concept…)

But: Objective-C had no tuples, so a final decision shouldn't happen until there is an agreement on best-practices for them...

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[DevAndArtist]

I forgot something in my previous post:

@require_argument_label
func foo(block: (boo: Int) -> Void) { /* pass boo to block */ }

foo() { boo in // do is enforced here
	/* do some work*/
}

···

--
Adrian Zubarev

Am 20. April 2016 bei 19:59:23, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

@require_argument_label

[Tino]

Do you think it might be possible to add some optional extra flag to the language to enforce argument labeling. Not only for tuples as I started the discussion with but also for argument labels on blocks/closures?

I'm quite skeptical when it comes to enforce behavior (unless it's the way I prefer it anyways — and in this case, I think the carrot is better than the stick:
Leave the language as it is, but let the tools add the "right" labels by default (sadly, there is no thing like Xcode-evolution…

[Haravikk3]

I think the important thing to remember is that the label check is intended to prevent cases like this:

  let a:(left:Int, right:Int) = (1, 2)
  var b:(right:Int, left:Int) = a

While the two tuples are compatible by type, the meaning of the values may differ due to the different labels; in this case the values are represented in a different order that a developer should have to explicitly reverse to ensure they aren’t making a mistake, or they could represent radically different concepts altogether.

It’s certainly annoying when the labels are only different due to minor differences, but the compiler doesn’t know that. So yeah, I think that in any case where there are external labels that differ a warning should be raised; this comes down to being able to later ignore types of warnings, which could avoid the boiler-plate in future.

The alternative would be if we had some syntax for mapping parameters more cleanly, for example:

  hi(1, y: 2, fn: sum1 where left = lhs, right = rhs)

Or something along those lines anyway?

···

On 21 Apr 2016, at 06:18, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 20, 2016, at 4:47 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

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

So maybe I think about this incorrectly, but I always think of any parameter without an explicit label to have one that is equal to the parameter name. So these two functions signatures would be equivalent:

func sum1(lhs: Int, rhs: Int) -> Int
func sum2(lhs lhs: Int, rhs rhs: Int) -> Int

It’s only when you explicit “erase” the label where there is none:

func sum(_ lhs: Int, _ rhs: Int) -> Int

So back to the example above, it’s still somewhat odd that all of these are valid:

hi(1, y: 2, fn: sum1)
hi(1, y: 2, fn: sum2)
hi(1, y: 2, fn: sum) // makes the most sense, no label to labeled promotion

But if we did reject the differently labeled version, that would mean that we would need to declare the `Functor` above as:

typealias Functor = (Int, Int) -> Int

Is that better? I’m not terribly convinced that it is.

If `Functor` keeps the labels, I suspect it would just lead to additional boiler-plate code that would look like:

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

hi(1, y: 2, fn: { left, right in sum1(lhs: left, rhs: right) })

While it does seem technically correct, is that really the kind of code we want in Swift?

-David
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

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 { }

So maybe I think about this incorrectly, but I always think of any parameter without an explicit label to have one that is equal to the parameter name.

We’re going in that direction, but that is not currently the case for operators and subscript indices. As a community, we don’t have much real-world experience using Swift 3, but I don’t expect that either of those cases would get better by requiring labels by default and requiring _ to suppress them.

So these two functions signatures would be equivalent:

func sum1(lhs: Int, rhs: Int) -> Int
func sum2(lhs lhs: Int, rhs rhs: Int) -> Int

It’s only when you explicit “erase” the label where there is none:

func sum(_ lhs: Int, _ rhs: Int) -> Int

So back to the example above, it’s still somewhat odd that all of these are valid:

hi(1, y: 2, fn: sum1)
hi(1, y: 2, fn: sum2)
hi(1, y: 2, fn: sum) // makes the most sense, no label to labeled promotion

But if we did reject the differently labeled version, that would mean that we would need to declare the `Functor` above as:

typealias Functor = (Int, Int) -> Int

I agree that eliminating relabeling would force this.

Is that better? I’m not terribly convinced that it is.

Me neither.

Off in crazy space for a bit, but one could argue that this style of design would imply that you should be able to call this example like this:

hi(1, y: 2, fn: { sum1(lhs: $left, rhs: $right) })

since the only sensible names for the parameters come from context.

-Chris

···

On Apr 20, 2016, at 10:18 PM, David Owens II <david@owensd.io> wrote:

[DevAndArtist]

Personally I'm fine with the way it is right now, but I do miss enforced labels at some point. At least it would be 'nice to have' feature like we already have @autoclosure or @noescape to enforce some specific behaviour.

I started the discussion about enforcing argument labels on tuples but with your feedback I totally see the point why this shouldn’t be something backed inside the language by default.

Optional way to enforce the usage of correct/strict/explicit labels could provide better readability from my point of view.

Remember the idea of cascading methods/initializer? For class types it’s almost possible to build that feature by yourself, but there is one problem that was discussed back then. What do we use inside the trailing closure to access the instance.
Sure we could give it a custom name or just use `$0`.

let instance = ClassA() {

      // customName in
      // or $0
}

// imagine we had something optional like
class ClassB {

      @require_explicit_label_usage
      init(closure: (this: ClassB) -> Void) {

            closure(this: self)
      }
      func foo() {}
}

// now we could use it like

let b = ClassB() { this in // can be omitted due the use of @require_explicit_label_usage

       this.foo()
}

// I'll use ++ operator just for the example here

@require_explicit_label_usage
prefix func ++ (tuple: (exp: Int, earned: Int)) -> Int {

     return tuple.apples + tuple.amount
}

// this operator will only overload when the right labeling is applied to the tuple

++(exp: 10, earned: 5) // result would be 15

// the operator wont work with
++(100, 50)
// give another dev this snippet and ask him what 100 and 50 means

This example is very abstract but I'm sure you should get the point of the possible need of an optional label enforcement.

By the way, why does Swift allow something like this anyway?

var a = (a: 10) // is of type Int

Where something like the next example is not allowed at all:

var a: (a: Int) = (a: 10)

···

--
Adrian Zubarev

Am 21. April 2016 bei 09:14:16, Haravikk via swift-evolution (swift-evolution@swift.org) schrieb:

I think the important thing to remember is that the label check is intended to prevent cases like this:

let a:(left:Int, right:Int) = (1, 2)
var b:(right:Int, left:Int) = a

While the two tuples are compatible by type, the meaning of the values may differ due to the different labels; in this case the values are represented in a different order that a developer should have to explicitly reverse to ensure they aren’t making a mistake, or they could represent radically different concepts altogether.

It’s certainly annoying when the labels are only different due to minor differences, but the compiler doesn’t know that. So yeah, I think that in any case where there are external labels that differ a warning should be raised; this comes down to being able to later ignore types of warnings, which could avoid the boiler-plate in future.

The alternative would be if we had some syntax for mapping parameters more cleanly, for example:

hi(1, y: 2, fn: sum1 where left = lhs, right = rhs)

Or something along those lines anyway?

On 21 Apr 2016, at 06:18, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 20, 2016, at 4:47 PM, Chris Lattner <clattner@apple.com> wrote:

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

So maybe I think about this incorrectly, but I always think of any parameter without an explicit label to have one that is equal to the parameter name. So these two functions signatures would be equivalent:

func sum1(lhs: Int, rhs: Int) -> Int
func sum2(lhs lhs: Int, rhs rhs: Int) -> Int

It’s only when you explicit “erase” the label where there is none:

func sum(_ lhs: Int, _ rhs: Int) -> Int

So back to the example above, it’s still somewhat odd that all of these are valid:

hi(1, y: 2, fn: sum1)
hi(1, y: 2, fn: sum2)
hi(1, y: 2, fn: sum) // makes the most sense, no label to labeled promotion

But if we did reject the differently labeled version, that would mean that we would need to declare the `Functor` above as:

typealias Functor = (Int, Int) -> Int

Is that better? I’m not terribly convinced that it is.

If `Functor` keeps the labels, I suspect it would just lead to additional boiler-plate code that would look like:

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

hi(1, y: 2, fn: { left, right in sum1(lhs: left, rhs: right) })

While it does seem technically correct, is that really the kind of code we want in Swift?

-David
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution