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

An interesting take on arg label/name, granted this is including destructuring of obj literals (so one level down from the method sig, but which is not without analogy to what could be done to tuples with named fields). The main point of comparison is what the type of f1 and f2 are. This is

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

> As has been discussed exhaustively in this thread, Swift 3 function labels > don't convey the meaning of parameters, they are almost always prepositional > phrases that don't make sense apart from the primary function name they are > attached to. Why should there be different rules for

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

> On Jul 3, 2016, at 11:50 PM, Tino Heth via swift-evolution > wrote: > > Overall, -1. > > I agree that labels should not affect the type, but imho the current status > (Swift 2.3 — I haven't checked Version 3) is fine, and the proposal doesn't > achieve what it

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

Overall, -1. I agree that labels should not affect the type, but imho the current status (Swift 2.3 — I haven't checked Version 3) is fine, and the proposal doesn't achieve what it says in the title: For me, that is no question of types at all, but only of names: var a: (Int, z: Int) -> Void =

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

Ever considered looking at how typescript handles argument names in object literal deconstruction? Regards (From mobile) On Jul 3, 2016, at 10:36 PM, Pyry Jahkola via swift-evolution wrote: >> On 30 Jun 2016, Chris Lattner wrote: >> >> The review of "SE-0111:

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

> On 30 Jun 2016, Chris Lattner wrote: > > The review of "SE-0111: Remove type system significance of function argument > labels" begins now and runs through July 4. The proposal is available here: > > >

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

Those aren't two "interchangeable" types in your example; it's the same type with two aliases. By contrast, the tuple types `(x: Int, y: Int)` and `(a: Int, b: Int)` are distinct, as I illustrated above. You are correct that one of the unique aspects of labeled tuple types would no longer be so

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

typealias Point = (x: Int, y: Int) typealias Dimensions = (x: Int, y: Int) let point: Point = (x: 5, y: 5) let dimensions = point Fundamentally different concepts may have labels happen to be the same. Structs protect against this conversion, tuples don't. Explicit protocol conformance is

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

On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt wrote: > Tuples are inherently interchangable. If you want to avoid this, the > safest way is to use a struct. > ``` typealias Foo = (a: Int, b: Int) typealias Bar = (c: Int, d: Int) var foo: Foo = (1, 2) var bar: Bar = (3,

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

Tuples are inherently interchangable. If you want to avoid this, the safest way is to use a struct. Labels/naming shouldn't be relied on to provide type information, this is why implicit conformance to protocols is disallowed. From James F > On 2 Jul 2016, at 06:43, Xiaodi Wu

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

What's the basis for your claim that tuples are best passed around without their labels? If I have `typealias CartesianCoordinates = (x: Double, y: Double)`, these labels are absolutely meaningful, and I would not want them to be interchangeable with a hypothetical `typealias PolarCoordinates =

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

> A parameter list of (inout Int, @noescape Int -> ()) is just a ‘tuple + > annotations’ relevant to use in parameter lists. If you can restrict this > pseudo-type to the appropriate context, like we are heading towards with > disallowing ImplicityUnwrappedOptional in function signatures, why

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

> On 2 Jul 2016, at 05:03, Austin Zheng wrote: > > >> On Jul 1, 2016, at 8:55 PM, James Froggatt wrote: >> >> >> On 2 Jul 2016, at 04:46, Austin Zheng wrote: >> >>> >>> >>> This functionality naturally falls out of any

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

> On Jul 1, 2016, at 8:55 PM, James Froggatt wrote: > > > On 2 Jul 2016, at 04:46, Austin Zheng > wrote: > >> >> >> This functionality naturally falls out of any decent proposal for variadic >> generics. I'd

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

> On 2 Jul 2016, at 04:46, Austin Zheng wrote: > > >> On Jul 1, 2016, at 8:37 PM, James Froggatt wrote: >> >> >> On 2 Jul 2016, at 04:22, Austin Zheng wrote: >> >>> On Jul 1, 2016, at 8:15 PM, James Froggatt via

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

> On Jul 1, 2016, at 8:37 PM, James Froggatt wrote: > > > On 2 Jul 2016, at 04:22, Austin Zheng > wrote: > >> >>> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution >>>

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

> On 2 Jul 2016, at 04:22, Austin Zheng wrote: > > >> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution >> wrote: >> >> ‘If I understand the other discussions regarding the evolution of Swift's >> function arguments model, the

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

> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution > wrote: > > ‘If I understand the other discussions regarding the evolution of Swift's > function arguments model, the similarity to tuples with labeled components is > a historical artifact and now

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

‘If I understand the other discussions regarding the evolution of Swift's function arguments model, the similarity to tuples with labeled components is a historical artifact and now merely coincidental.’ Is it though? Couldn't the current confusing situation of tuple labels in the type system

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

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0111: Remove type system significance of function > argument labels" begins now and runs through July 4. The proposal is > available here: > > >

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

* What is your evaluation of the proposal? a reluctant +1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes. * Does this proposal fit well with the feel and direction of Swift? Yes. * If you have used other languages or libraries with a

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

> On Jul 1, 2016, at 7:37 AM, Brad Hilton via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > -1. Argument labels can have meaning and are very useful, especially for > default parameter names in closures: > > ```// Declaration > func

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

> On Jul 1, 2016, at 1:30 AM, Taras Zakharko via swift-evolution > wrote: > > Jordan, Thanks for the very insightful explanation! It all makes a lot of > sense in perspective. > > Apparently I was thinking about this issue a bit while I was sleeping, and > now it

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

Mostly I was just hedging my bets, but the main one I can think of is that enum cases still use tuples, which means they don’t have distinct argument labels and preserve the labels in switches. There’s also a bunch of implementation improvements we can make (like fixing mangling and printing of

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

> What is your evaluation of the proposal? -1. Argument labels can have meaning and are very useful, especially for default parameter names in closures: ```// Declaration func handleResponse(handler: (response: Response) -> ()) // Callsite handleResponse { response in // response automatically

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

Jordan, Thanks for the very insightful explanation! It all makes a lot of sense in perspective. Apparently I was thinking about this issue a bit while I was sleeping, and now it seems to me that part of the problem is because one strives for the function signature to be linguistically

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

Great story! What gets us from 95% to 100%? :) > On 1 Jul 2016, at 05:33, Jordan Rose via swift-evolution > wrote: > > >>> On Jun 30, 2016, at 13:36, Taras Zakharko via swift-evolution >>> wrote: >>> >>> >>> On 30 Jun 2016, at 22:11,

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

> On 30 Jun 2016, at 22:38, Austin Zheng wrote: > > You might like the alternative I added > (https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > >

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

You might like the alternative I added ( https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md). It basically goes the other way: keep the semantic significance of labels, and make them mean something by prohibiting converting between different

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

On 30.06.2016 21:37, Sean Heber via swift-evolution wrote: This mostly makes sense to me and it seems like mostly a good idea, but take this example: func doSomething(x: Int, y: Int) -> Bool { return true } let x = doSomething x(10, 10) Is it then legal to do this?: x(blahblah:10,

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

This is a false dichotomy. The language can support tuples without requiring that function application be modeled in terms of tuples. That ship has sailed long ago, and there is no reason to revisit it without a compelling reason (and "function argument lists look sort of like tuples" is not to me

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

I’d also like to know what the answer to this is before giving my vote for or against the proposal. > On 30 Jun 2016, at 20:37, Sean Heber via swift-evolution > wrote: > > This mostly makes sense to me and it seems like mostly a good idea, but take > this example:

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

On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote: > > > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hello Swift community, > > > > The review of "SE-0111: Remove type system

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

This is a good point. I feel like calling `x` with any sort of argument labels should be prohibited. I don't think there's any expressivity penalty for doing so (especially since tuple splat is gone); plus, once a function is reified as a value (as opposed to being invoked by naming it directly),

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

This mostly makes sense to me and it seems like mostly a good idea, but take this example: func doSomething(x: Int, y: Int) -> Bool { return true } let x = doSomething x(10, 10) Is it then legal to do this?: x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10) That would seem