[Review] SE-0066: Standardize function type argument syntax to require parentheses


(Thorsten Seitz) #1

I am strictly against requiring parentheses in closure expressions. Parentheses are visual clutter if not really needed and for a closure expression there is no need for parentheses as the parameter list is already nicely bracketed by `{ ... in`.

Actually I would argue that parentheses around parameter lists in closure expressions should be prohibited for that reason.

I'm not fond of requiring parentheses around single non-tuple parameters in type declarations either but I could probably grudgingly live with that change.

But keep away from closure expressions, please! There is nothing ambiguous there.

-Thorsten

···

Am 27. April 2016 um 00:07 schrieb David Owens II via swift-evolution <swift-evolution@swift.org>:

On Apr 26, 2016, at 1:31 PM, Chris Lattner <clattner@apple.com> wrote:

On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

What is your evaluation of the proposal?

I reluctantly agree with the proposal with the following caveat: I do not agree with the rationale to support being able to choose to omit the () for the parameter list of the closure declaration.

I see no cohesive argument that says that the parens should be required in some cases but not in others when talking about parameter lists.

I believe the proposal should be amended that the following should be the only allowable forms:

Hi David,

To be clear, this proposal is not about changing closure expressions, it was just a FAQ, and the section at the end is simply my personal opinion. Changing closure expression syntax would be a separate proposal.

My argument is changing the parameter list in one context but not the other is only solving one of the potentially ambiguous use cases instead of the general case. My opinion is they should be changed as the same time if they are going to be changed at all.

-David

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


(Vladimir) #2

But keep away from closure expressions, please! There is nothing ambiguous

> there.

Really?

func z1(block: (Int,Int) -> Void) {
     block(1,2)
}

z1 { x, y in print(x,y)} //
z1 { x in print(x.0, x.1)} // ???
z1 { (x, y) in print(x, y)} //

func z2(block: ((Int,Int)) -> Void) {
     block((1,2))
}

z2 { x, y in print(x,y)} // ???
z2 { x in print(x.0, x.1)}
z2 { (x, y) in print(x, y)} // ???
//z2 { ((x, y)) in print(x, y)} // compilation error

// this will compile, but
runtime error
let ft : (Int,Int) -> Void = { x in print(x)} // hm..
ft(1, 2)

···

On 27.04.2016 11:53, Thorsten Seitz via swift-evolution wrote:

I am strictly against requiring parentheses in closure expressions.
Parentheses are visual clutter if not really needed and for a closure
expression there is no need for parentheses as the parameter list is
already nicely bracketed by `{ ... in`.
Actually I would argue that parentheses around parameter lists in closure
expressions should be prohibited for that reason.

I'm not fond of requiring parentheses around single non-tuple parameters in
type declarations either but I could probably grudgingly live with that change.
But keep away from closure expressions, please! There is nothing ambiguous
there.

-Thorsten

Am 27. April 2016 um 00:07 schrieb David Owens II via swift-evolution > <swift-evolution@swift.org>:

On Apr 26, 2016, at 1:31 PM, Chris Lattner <clattner@apple.com >>> <mailto:clattner@apple.com>> wrote:

On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

*What is your evaluation of the proposal?
*
I reluctantly agree with the proposal with the following caveat: I do
not agree with the rationale to support being able to choose to
omit the () for the parameter list of the closure declaration.

I see no cohesive argument that says that the parens should be required
in some cases but not in others when talking about parameter lists.

I believe the proposal should be amended that the following should be
the only allowable forms:

Hi David,

To be clear, this proposal is not about changing closure expressions, it
was just a FAQ, and the section at the end is simply my personal
opinion. Changing closure expression syntax would be a separate proposal.

My argument is changing the parameter list in one context but not the
other is only solving one of the potentially ambiguous use cases instead
of the general case. My opinion is they should be changed as the same
time if they are going to be changed at all.

-David

_______________________________________________
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


(Thorsten Seitz) #3

> But keep away from closure expressions, please! There is nothing ambiguous
> there.

Really?

Ok, you got me there :slight_smile:
I have to clarify: no ambiguity if parentheses would be prohibited around parameter lists in closure expressions like I suggested.
Furthermore the current implementation seems to do some auto-(un)splatting which should go away.

func z1(block: (Int,Int) -> Void) {
   block(1,2)
}

z1 { x, y in print(x,y)} //

(Int, Int) is a parameter list, so this is ok

z1 { x in print(x.0, x.1)} // ???

This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) is a parameter list and not a tuple.
Seems to be tuple unsplatting at work here.

z1 { (x, y) in print(x, y)} //

This should not work for the given definition of z1 as (x, y) is a tuple.

func z2(block: ((Int,Int)) -> Void) {
   block((1,2))
}

z2 { x, y in print(x,y)} // ???

This should not work IMO (tuple splatting at work here)

z2 { x in print(x.0, x.1)}

Fine, as x is a tuple.

z2 { (x, y) in print(x, y)} // ???

Fine, as (x, y) is a tuple. This raises another issue, though: this is using pattern matching without having to write `let` or `case let`. That’s probably a good thing and I’d rather like to get rid of `let` for bindings in pattern matching in other places.

//z2 { ((x, y)) in print(x, y)} // compilation error

This should not work IMO as parentheses should not be allowed around argument lists in closure expressions.

// this will compile, but
runtime error
let ft : (Int,Int) -> Void = { x in print(x)} // hm..
ft(1, 2)

There is no runtime error in my playground.
The result printed is (1, 2)

This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) is a parameter list and not a tuple.
You would have to write
let ft : (Int,Int) -> Void = { x, y in print(x, y) } // 1 2
or
let ft : ((Int,Int)) -> Void = { x in print(x) } // (1, 2)

To rehash:

Rules for function type definitions:
- parentheses are required around argument lists of more than one argument, i.e. (Int, Int) -> Void (same as in SE-0066)
- parentheses are required around argument lists with a single tuple argument, i.e. ((Int, Int)) -> Void (same as in SE-0066)
- parentheses are prohibited around single non-tuple arguments, i.e. Int -> Void (different from SE-0066)

Rule for argument lists in closure expressions:
- parentheses are prohibited around the argument list (as it is clearly enclosed by `{ … in`, therefore parentheses can only be used for tuples (different from current state)

This would result in nice unambiguous code without unnecessary parentheses.

-Thorsten

···

Am 27.04.2016 um 14:16 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:

On 27.04.2016 11:53, Thorsten Seitz via swift-evolution wrote:

I am strictly against requiring parentheses in closure expressions.
Parentheses are visual clutter if not really needed and for a closure
expression there is no need for parentheses as the parameter list is
already nicely bracketed by `{ ... in`.
Actually I would argue that parentheses around parameter lists in closure
expressions should be prohibited for that reason.

I'm not fond of requiring parentheses around single non-tuple parameters in
type declarations either but I could probably grudgingly live with that change.
But keep away from closure expressions, please! There is nothing ambiguous
there.

-Thorsten

Am 27. April 2016 um 00:07 schrieb David Owens II via swift-evolution >> <swift-evolution@swift.org>:

On Apr 26, 2016, at 1:31 PM, Chris Lattner <clattner@apple.com >>>> <mailto:clattner@apple.com <mailto:clattner@apple.com>>> wrote:

On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

*What is your evaluation of the proposal?
*
I reluctantly agree with the proposal with the following caveat: I do
not agree with the rationale to support being able to choose to
omit the () for the parameter list of the closure declaration.

I see no cohesive argument that says that the parens should be required
in some cases but not in others when talking about parameter lists.

I believe the proposal should be amended that the following should be
the only allowable forms:

Hi David,

To be clear, this proposal is not about changing closure expressions, it
was just a FAQ, and the section at the end is simply my personal
opinion. Changing closure expression syntax would be a separate proposal.

My argument is changing the parameter list in one context but not the
other is only solving one of the potentially ambiguous use cases instead
of the general case. My opinion is they should be changed as the same
time if they are going to be changed at all.

-David

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

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


(David Owens II) #4

You forgot that parentheses are required for labeled closures with type information:

x.sorted { (x: Int, y: Int) in x > y }

You'd have to handle that case as well.

x.sorted { x: Int, y: Int in x > y }

I think the above leads to potentially ambiguous parsing constructs.

···

Sent from my iPhone

On Apr 27, 2016, at 1:18 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

Am 27.04.2016 um 14:16 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:

> But keep away from closure expressions, please! There is nothing ambiguous
> there.

Really?

Ok, you got me there :slight_smile:
I have to clarify: no ambiguity if parentheses would be prohibited around parameter lists in closure expressions like I suggested.
Furthermore the current implementation seems to do some auto-(un)splatting which should go away.

func z1(block: (Int,Int) -> Void) {
   block(1,2)
}

z1 { x, y in print(x,y)} //

(Int, Int) is a parameter list, so this is ok

z1 { x in print(x.0, x.1)} // ???

This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) is a parameter list and not a tuple.
Seems to be tuple unsplatting at work here.

z1 { (x, y) in print(x, y)} //

This should not work for the given definition of z1 as (x, y) is a tuple.

func z2(block: ((Int,Int)) -> Void) {
   block((1,2))
}

z2 { x, y in print(x,y)} // ???

This should not work IMO (tuple splatting at work here)

z2 { x in print(x.0, x.1)}

Fine, as x is a tuple.

z2 { (x, y) in print(x, y)} // ???

Fine, as (x, y) is a tuple. This raises another issue, though: this is using pattern matching without having to write `let` or `case let`. That’s probably a good thing and I’d rather like to get rid of `let` for bindings in pattern matching in other places.

//z2 { ((x, y)) in print(x, y)} // compilation error

This should not work IMO as parentheses should not be allowed around argument lists in closure expressions.

// this will compile, but
runtime error
let ft : (Int,Int) -> Void = { x in print(x)} // hm..
ft(1, 2)

There is no runtime error in my playground.
The result printed is (1, 2)

This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) is a parameter list and not a tuple.
You would have to write
let ft : (Int,Int) -> Void = { x, y in print(x, y) } // 1 2
or
let ft : ((Int,Int)) -> Void = { x in print(x) } // (1, 2)

To rehash:

Rules for function type definitions:
- parentheses are required around argument lists of more than one argument, i.e. (Int, Int) -> Void (same as in SE-0066)
- parentheses are required around argument lists with a single tuple argument, i.e. ((Int, Int)) -> Void (same as in SE-0066)
- parentheses are prohibited around single non-tuple arguments, i.e. Int -> Void (different from SE-0066)

Rule for argument lists in closure expressions:
- parentheses are prohibited around the argument list (as it is clearly enclosed by `{ … in`, therefore parentheses can only be used for tuples (different from current state)

This would result in nice unambiguous code without unnecessary parentheses.

-Thorsten

On 27.04.2016 11:53, Thorsten Seitz via swift-evolution wrote:
I am strictly against requiring parentheses in closure expressions.
Parentheses are visual clutter if not really needed and for a closure
expression there is no need for parentheses as the parameter list is
already nicely bracketed by `{ ... in`.
Actually I would argue that parentheses around parameter lists in closure
expressions should be prohibited for that reason.

I'm not fond of requiring parentheses around single non-tuple parameters in
type declarations either but I could probably grudgingly live with that change.
But keep away from closure expressions, please! There is nothing ambiguous
there.

-Thorsten

Am 27. April 2016 um 00:07 schrieb David Owens II via swift-evolution >>> <swift-evolution@swift.org>:

On Apr 26, 2016, at 1:31 PM, Chris Lattner <clattner@apple.com >>>>> <mailto:clattner@apple.com>> wrote:

On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

*What is your evaluation of the proposal?
*
I reluctantly agree with the proposal with the following caveat: I do
not agree with the rationale to support being able to choose to
omit the () for the parameter list of the closure declaration.

I see no cohesive argument that says that the parens should be required
in some cases but not in others when talking about parameter lists.

I believe the proposal should be amended that the following should be
the only allowable forms:

Hi David,

To be clear, this proposal is not about changing closure expressions, it
was just a FAQ, and the section at the end is simply my personal
opinion. Changing closure expression syntax would be a separate proposal.

My argument is changing the parameter list in one context but not the
other is only solving one of the potentially ambiguous use cases instead
of the general case. My opinion is they should be changed as the same
time if they are going to be changed at all.

-David

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


(Thorsten Seitz) #5

You forgot that parentheses are required for labeled closures with type information:

x.sorted { (x: Int, y: Int) in x > y }

You'd have to handle that case as well.

That’s a single tuple argument.

x.sorted { x: Int, y: Int in x > y }

And that’s an argument list with two arguments.

I think the above leads to potentially ambiguous parsing constructs.

Why? The `in` should be unambiguously ending the argument list without parsing issues, shouldn’t it?

-Thorsten

···

Am 28.04.2016 um 00:38 schrieb David Owens II <david@owensd.io>:

Sent from my iPhone

On Apr 27, 2016, at 1:18 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Am 27.04.2016 um 14:16 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

> But keep away from closure expressions, please! There is nothing ambiguous
> there.

Really?

Ok, you got me there :slight_smile:
I have to clarify: no ambiguity if parentheses would be prohibited around parameter lists in closure expressions like I suggested.
Furthermore the current implementation seems to do some auto-(un)splatting which should go away.

func z1(block: (Int,Int) -> Void) {
   block(1,2)
}

z1 { x, y in print(x,y)} //

(Int, Int) is a parameter list, so this is ok

z1 { x in print(x.0, x.1)} // ???

This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) is a parameter list and not a tuple.
Seems to be tuple unsplatting at work here.

z1 { (x, y) in print(x, y)} //

This should not work for the given definition of z1 as (x, y) is a tuple.

func z2(block: ((Int,Int)) -> Void) {
   block((1,2))
}

z2 { x, y in print(x,y)} // ???

This should not work IMO (tuple splatting at work here)

z2 { x in print(x.0, x.1)}

Fine, as x is a tuple.

z2 { (x, y) in print(x, y)} // ???

Fine, as (x, y) is a tuple. This raises another issue, though: this is using pattern matching without having to write `let` or `case let`. That’s probably a good thing and I’d rather like to get rid of `let` for bindings in pattern matching in other places.

//z2 { ((x, y)) in print(x, y)} // compilation error

This should not work IMO as parentheses should not be allowed around argument lists in closure expressions.

// this will compile, but
runtime error
let ft : (Int,Int) -> Void = { x in print(x)} // hm..
ft(1, 2)

There is no runtime error in my playground.
The result printed is (1, 2)

This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) is a parameter list and not a tuple.
You would have to write
let ft : (Int,Int) -> Void = { x, y in print(x, y) } // 1 2
or
let ft : ((Int,Int)) -> Void = { x in print(x) } // (1, 2)

To rehash:

Rules for function type definitions:
- parentheses are required around argument lists of more than one argument, i.e. (Int, Int) -> Void (same as in SE-0066)
- parentheses are required around argument lists with a single tuple argument, i.e. ((Int, Int)) -> Void (same as in SE-0066)
- parentheses are prohibited around single non-tuple arguments, i.e. Int -> Void (different from SE-0066)

Rule for argument lists in closure expressions:
- parentheses are prohibited around the argument list (as it is clearly enclosed by `{ … in`, therefore parentheses can only be used for tuples (different from current state)

This would result in nice unambiguous code without unnecessary parentheses.

-Thorsten

On 27.04.2016 11:53, Thorsten Seitz via swift-evolution wrote:

I am strictly against requiring parentheses in closure expressions.
Parentheses are visual clutter if not really needed and for a closure
expression there is no need for parentheses as the parameter list is
already nicely bracketed by `{ ... in`.
Actually I would argue that parentheses around parameter lists in closure
expressions should be prohibited for that reason.

I'm not fond of requiring parentheses around single non-tuple parameters in
type declarations either but I could probably grudgingly live with that change.
But keep away from closure expressions, please! There is nothing ambiguous
there.

-Thorsten

Am 27. April 2016 um 00:07 schrieb David Owens II via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

On Apr 26, 2016, at 1:31 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com> >>>>>> <mailto:clattner@apple.com <mailto:clattner@apple.com>>> wrote:

On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

*What is your evaluation of the proposal?
*
I reluctantly agree with the proposal with the following caveat: I do
not agree with the rationale to support being able to choose to
omit the () for the parameter list of the closure declaration.

I see no cohesive argument that says that the parens should be required
in some cases but not in others when talking about parameter lists.

I believe the proposal should be amended that the following should be
the only allowable forms:

Hi David,

To be clear, this proposal is not about changing closure expressions, it
was just a FAQ, and the section at the end is simply my personal
opinion. Changing closure expression syntax would be a separate proposal.

My argument is changing the parameter list in one context but not the
other is only solving one of the potentially ambiguous use cases instead
of the general case. My opinion is they should be changed as the same
time if they are going to be changed at all.

-David

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

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