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

[Chris Lattner via swift-evolution]

On Apr 20, 2016, at 10:18 PM, David Owens II  wrote:
>>> 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

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

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

[Adrian Zubarev via swift-evolution]

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`.

```swift
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 
 wrote:


On Apr 20, 2016, at 4:47 PM, Chris Lattner  wrote:

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

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

[Haravikk via swift-evolution]

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 
>  wrote:
> 
>> 
>> On Apr 20, 2016, at 4:47 PM, Chris Lattner > > wrote:
>> 
>> On Apr 20, 2016, at 12:31 PM, David Owens II via swift-evolution 
>> 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 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evol

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

[David Owens II via swift-evolution]

> On Apr 20, 2016, at 4:47 PM, Chris Lattner  wrote:
> 
> On Apr 20, 2016, at 12:31 PM, David Owens II via swift-evolution 
> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

On Apr 20, 2016, at 12:31 PM, David Owens II via swift-evolution 
 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___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave via swift-evolution]

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

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

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

[David Owens II via swift-evolution]

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

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

[Tino Heth via swift-evolution]

> 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… ;-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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

```swift

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-evolut...@haravikk.me) schrieb:

organization's policy___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

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

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

[Austin Zheng via swift-evolution]

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 
>  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?
> 
> ```swift
> 
> @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 (2...@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

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

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

[William Dillon via swift-evolution]

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

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

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

[Adrian Zubarev via swift-evolution]

I forgot something in my previous post:

```swift

@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.zuba...@devandartist.com) schrieb:

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

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

[Adrian Zubarev via swift-evolution]

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?

```swift

@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 (2...@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

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

[Austin Zheng via swift-evolution]

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

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

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

[Tino Heth via swift-evolution]

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

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

[Adrian Zubarev via swift-evolution]

There is no data type problem I'm trying to solve, also I could life with 
anonymous tuples. 

Remember the old VFL (Visual Format Language) for AutoLayout? Right now I'm 
building a small library which will do the same thing with some extra options. 

Enforced argument labeling will result in some good syntax sugar for my 
library. 

For example a VFL string "H:|-10-[view]" might look lile this '|-(margin: 
10)-(view)' with some custom operator magic, labeled tuples and actual view 
instances compared to the old string parsing version. 

Lets say I want to build a more complex VFL layout: 

|-(margin: 10, option: .CenterBoth, priority: 400)-(view)-(otherView)-| 

Developer A might just ignore the labeling and write: |-(10, .CenterBoth, 
400)-(view)-(otherView)-| 

A half year later developer B will read this code and wonder whats the meaning 
of these values of the tuple. 

In your example you're totally right that using internal anonymous tuples might 
be easier but as you said yourself one could reconstruct the tuple with the 
corresponding labels.

-- 
Adrian Zubarev 

Am 20. April 2016 um 17:40:57, William Dillon 
(will...@housedillon.com(mailto:will...@housedillon.com)) schrieb:

> 
> At the moment, I'm against this (though it's possible to convince me with 
> sufficiently reasoned arguments).
> 
> The reason being is that if I want the protection from the compiler, I think 
> I would construct a struct for the purpose. I don't believe that making a 
> struct would create enough overhead that a tuple would be preferable in this 
> case. 
> 
> An example of a scenario where this change would be inconvenient would be the 
> case where you're building an application composed of libraries using 
> different conventions. Consider that you're doing signals processing with 
> complex numbers: 
> 
> The filtering is coming from library A, that uses (r: Double, i: Double): 
> func firFilter(input: [(r: Double, i: Double)], taps [(r: Double, i: 
> Double)]) -> [(r: Double, i: Double)] { }
> 
> The source driver uses anonymous tuples (Double, Double): 
> func getSamples() -> [(Double, Double)] { }
> 
> And the plotting library (B) uses real and imaginary spelled out (real: 
> Double, imaginary: Double): 
> func plotSamples([real: Double, imaginary: Double)]) { }
> 
> This is a somewhat contrived example, and I know that it would be possible to 
> re-construct the tuples so that they match, but that would be ugly at best 
> and inefficient at worst. 
> 
> What is the problem you're trying to solve that can't be fixed using policy 
> (thou shalt label tuple arguments) at your organization, or structs? 
> 
> Cheers, 
> - Will
> 
> 
> > On Apr 20, 2016, at 6:23 AM, Adrian Zubarev via swift-evolution 
> > mailto: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? 
> > 
> > ```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@swift.org(mailto: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

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

[Adrian Zubarev via swift-evolution]

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