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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)