Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 7, 2017, at 1:05 AM, Xiaodi Wu wrote: > > This is not what was meant during discussion about re-evaluating SE-0110. > Tuples already behave as described, but function argument lists are not > tuples and have not been for a very long time: see SE-0029, SE-0066. >

Re: [swift-evolution] Proposal: Always flatten the single element tuple

This is not what was meant during discussion about re-evaluating SE-0110. Tuples already behave as described, but function argument lists are not tuples and have not been for a very long time: see SE-0029, SE-0066. Also, consider SE-0046, which makes possible labels in single-argument argument

Re: [swift-evolution] Proposal: Always flatten the single element tuple

func add2(_ pair: (Int, Int)) -> Int { return pair.0 + pair.1 } consider the follows let _add2 = add2 // add2 have the typeof `((Int, Int)) -> Int`, it should flatten to `(Int, Int) -> Int` so these two lines are also acceptable [(1, 2)].map(add1) [(1, 2)].map(add2) this proposal is

Re: [swift-evolution] Proposal: Always flatten the single element tuple

The inline cases make sense to me, but my concern for ambiguity are because we can define both of these functions: func add1(_ x: Int, _ y: Int) -> Int { return x + y } func add2(_ pair: (Int, Int)) -> Int { return pair.0 + pair.1 } // What's the behavior here?

Re: [swift-evolution] Proposal: Always flatten the single element tuple

a PR is create: https://github.com/apple/swift-evolution/pull/722 2017-06-07 10:15 GMT+08:00 Susan Cheng : > Introduction > > Because the painful of SE-0110, here is a proposal to clarify the tuple > syntax. > > Proposed solution > 1. single element tuple always be

Re: [swift-evolution] Proposal: Always flatten the single element tuple

I like this a lot, but how do we solve for the function case? func add(_ x: Int, _ y: Int) -> Int { return x + y } [(1, 2)].map(add) Where does `map` with a function of `((Int, Int)) -> Int` fit in? > On Jun 6, 2017, at 10:15 PM, Susan Cheng via swift-evolution >

Re: [swift-evolution] Proposal: Always flatten the single element tuple

[(1, 2)].map({ x, y in x + y }) // this line is correct [(1, 2)].map({ tuple in tuple.0 + tuple.1 }) // this line should not accepted or [(1, 2)].map({ $0 + $1 }) // this line is correct [(1, 2)].map({ $0.0 + $0.1 }) // this line should not accepted it's because `((Int, Int)) -> Int`

Re: [swift-evolution] Proposal: Always flatten the single element tuple

it's also clear that these code will never be ambiguous [(1, 2)].map({ $0 }) // $0 always not a tuple, because arguments should be flattened 2017-06-07 11:21 GMT+08:00 Susan Cheng : > [(1, 2)].map({ x, y in x + y }) // this line is correct > [(1, 2)].map({ tuple in

[swift-evolution] Proposal: Always flatten the single element tuple

Introduction Because the painful of SE-0110, here is a proposal to clarify the tuple syntax. Proposed solution 1. single element tuple always be flattened let tuple1: (((Int))) = 0 // TypeOf(tuple1) == Int let tuple2: Int))), Int) = (0, 0) // TypeOf(tuple2) == (Int, Int) 2. function

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 8:19 PM, Mark Lacey wrote: > > Thanks for reminding me. It’s good to call out this case specifically. The > underlying reason that this is disallowed for Swift 4 is the same as the > underlying reason that a closure immediately passed as an argument

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 1:59 PM, Stephen Celis wrote: > >> On Jun 6, 2017, at 1:43 PM, Mark Lacey via swift-evolution >> wrote: >> >> Unless I am missing something this is an example of tuple destructuring. I’m >> looking for examples of

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

> On Jun 6, 2017, at 3:16 PM, Jens Persson wrote: > > Here are the four you asked me to report: > > https://bugs.swift.org/browse/SR-5127 > Single-tuple and multiple-argument function types should not be considered > equal > >

Re: [swift-evolution] Revisiting SE-0110

On 07.06.2017 0:45, Mark Lacey wrote: On Jun 6, 2017, at 11:45 AM, Vladimir.S wrote: On 06.06.2017 20:10, Mark Lacey via swift-evolution wrote: On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution > wrote:

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

Here are the four you asked me to report: https://bugs.swift.org/browse/SR-5127 Single-tuple and multiple-argument function types should not be considered equal https://bugs.swift.org/browse/SR-5128 Don't allow swapping a single-tuple function with a multiple-argument function

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 1:43 PM, Mark Lacey via swift-evolution > wrote: > > Unless I am missing something this is an example of tuple destructuring. I’m > looking for examples of other issues. The destructuring issue is the most pervasive, but as mentioned it also

Re: [swift-evolution] [Pitch] UnsafePointer.advanced(to:)

It's not an offset because the result is a different type of thing than the source Sent from my moss-covered three-handled family gradunza > On Jun 6, 2017, at 1:09 PM, Hooman Mehr wrote: > > >> On Jun 6, 2017, at 12:56 PM, Dave Abrahams via swift-evolution >>

Re: [swift-evolution] [Pitch] UnsafePointer.advanced(to:)

> On Jun 6, 2017, at 12:56 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jun 06 2017, Brent Royal-Gordon > wrote: > >>> On Jun 6, 2017, at 9:06 AM, Xiaodi Wu wrote:

Re: [swift-evolution] [Pitch] UnsafePointer.advanced(to:)

on Tue Jun 06 2017, Brent Royal-Gordon wrote: >> On Jun 6, 2017, at 9:06 AM, Xiaodi Wu wrote: >> >> Why would this be an extension on UnsafePointer and not KeyPath? > > 1. I can't come up with a name as good as `advanced(to:)` that would > be

Re: [swift-evolution] Revisiting SE-0110

On 06.06.2017 20:10, Mark Lacey via swift-evolution wrote: On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution > wrote: FWIW, after doing a project migration last night and this morning, I am reluctantly +1 for reverting

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

On 06.06.2017 19:41, Mark Lacey wrote: On Jun 6, 2017, at 4:00 AM, Vladimir.S > wrote: Mark, could you please also comment this inconsistencies / bugs : (swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-01-a-osx) func fooParam(_ x: Int, _ y: Int){} func

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Mon Jun 05 2017, Kevin Ballard wrote: > https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md > > > Overall it looks pretty good.

Re: [swift-evolution] Yet another fixed-size array spitball session

> On Jun 4, 2017, at 6:56 AM, Daryle Walker via swift-evolution > wrote: > > Static-sized arrays should not be shoved into being a tuple with funny > settings; that introduces subtleties into the tuple concept only because of > jammed-in array support. The fact 3

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 10:33 AM, John Holdsworth wrote: > > Hi Mark, > > one example of what was possible in Swift 3 but not convenient in Swift4 as > it stands is the following: > >let bookTuples = [(1, "john", "book", "novel", 9.99, []), >

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

On Tue, Jun 6, 2017 at 12:17 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > > On Tue, Jun 6, 2017 at 4:05 AM, Michael Savich via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> It recently occurred to me how nice it would be to be if we could avoid

Re: [swift-evolution] Revisiting SE-0110

Hi Mark, one example of what was possible in Swift 3 but not convenient in Swift4 as it stands is the following: let bookTuples = [(1, "john", "book", "novel", 9.99, []), (2, "john", "book", "novel", 9.99, ["chapt1", "chapt2"])] print("""

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

> On Tue, Jun 6, 2017 at 4:05 AM, Michael Savich via swift-evolution < > swift-evolution@swift.org> wrote: > >> It recently occurred to me how nice it would be to be if we could avoid >> declaring variables outside of loops that are only used inside them. I used >> google’s site specific search

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution > wrote: > > > FWIW, after doing a project migration last night and this morning, I am > reluctantly +1 for reverting SE-0110 and seeing a new proposal that can be > properly evaluated. The

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

> On Jun 6, 2017, at 4:00 AM, Vladimir.S wrote: > > Mark, could you please also comment this inconsistencies / bugs : > (swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-01-a-osx) > > func fooParam(_ x: Int, _ y: Int){} > func fooTuple(_ x: (Int, Int)) {} > > print("type of fooParam

Re: [swift-evolution] [Pitch] UnsafePointer.advanced(to:)

Why would this be an extension on UnsafePointer and not KeyPath? On Tue, Jun 6, 2017 at 10:28 Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > It won't happen for Swift 4, but I think we should eventually have APIs > like: > > extension UnsafePointer { > func

Re: [swift-evolution] Revisiting SE-0110

FWIW, after doing a project migration last night and this morning, I am reluctantly +1 for reverting SE-0110 and seeing a new proposal that can be properly evaluated. The split-the-difference compromise mentioned seems like just that, a compromise that will need to be revisited anyway. While

Re: [swift-evolution] Revisiting SE-0110

> Le 6 juin 2017 à 17:22, Shawn Erickson a écrit : > > > On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution > > wrote: > >> Le 6 juin 2017 à 15:30, Vladimir.S >

[swift-evolution] [Pitch] UnsafePointer.advanced(to:)

It won't happen for Swift 4, but I think we should eventually have APIs like: extension UnsafePointer { func advanced(to keyPath: KeyPath) -> UnsafePointer? } If keyPath referred to a stored property directly inside the value, this would return a pointer to that property. If

Re: [swift-evolution] Revisiting SE-0110

On 06.06.2017 16:53, Víctor Pimentel Rodríguez wrote: On Tue, Jun 6, 2017 at 3:30 PM, Vladimir.S via swift-evolution > wrote: I'm just trying to understand your opinion. Let me know, what result do you *expect* for this

Re: [swift-evolution] Revisiting SE-0110

On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > > Le 6 juin 2017 à 15:30, Vladimir.S a écrit : > > I'm just trying to understand your opinion. > Let me know, what result do you *expect* for this Swift4 code given what >

Re: [swift-evolution] [Meta] WWDC week

Works for me! > On Jun 6, 2017, at 1:14 AM, James Hillhouse wrote: > >  >>> On Jun 5, 2017, at 10:53 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>> On May 30, 2017, at 10:26 PM, Brent Royal-Gordon

Re: [swift-evolution] Revisiting SE-0110

On Tue, Jun 6, 2017 at 3:30 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > I'm just trying to understand your opinion. > Let me know, what result do you *expect* for this Swift4 code given what > SE-0066 requires for function types: > > func foo(x : (Int, Int))->() {} >

Re: [swift-evolution] Revisiting SE-0110

> Le 6 juin 2017 à 15:30, Vladimir.S a écrit : > > I'm just trying to understand your opinion. > Let me know, what result do you *expect* for this Swift4 code given what > SE-0066 requires for function types: > > func foo(x : (Int, Int))->() {} > > print(type(of: foo)) //

Re: [swift-evolution] Revisiting SE-0110

On 06.06.2017 15:32, Gwendal Roué wrote: Le 6 juin 2017 à 12:06, Vladimir.S > a écrit : On 06.06.2017 7:36, Gwendal Roué wrote: http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf The migrator does not properly

Re: [swift-evolution] Revisiting SE-0110

> Le 6 juin 2017 à 12:06, Vladimir.S a écrit : > > On 06.06.2017 7:36, Gwendal Roué wrote: >> http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf >>> The migrator does not properly distinquish between single-tuple and >>> multiple-argument

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

Oh, I admit I had never realized do could be used outside of an error handling context. Yeah, then I would agree then this change is probably unnecessary. Looking at the Swift guidebook it may be a good idea make it more explicit that the do statement is meant to be used for things other than

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

Mark, could you please also comment this inconsistencies / bugs : (swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-01-a-osx) func fooParam(_ x: Int, _ y: Int){} func fooTuple(_ x: (Int, Int)) {} print("type of fooParam is", type(of:fooParam)) // result: type of fooParam is (Int, Int) -> () print("type

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

If I recall correctly, it was discussed during a time when additive proposals were not in scope, so it could not be proposed. Since at the moment we are currently between Swift 4 and Swift 5 evolution, the topic is not in scope either. With respect to the idea itself, Taras's post--which appears

Re: [swift-evolution] Revisiting SE-0110

On 06.06.2017 7:36, Gwendal Roué wrote: http://adcdownload.apple.com/WWDC_2017/Xcode_9_beta/Xcode_9_beta_Release_Notes.pdf The migrator does not properly distinquish between single-tuple and multiple-argument function types as described in SE–0110, causing additional mismatched type errors

[swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

It recently occurred to me how nice it would be to be if we could avoid declaring variables outside of loops that are only used inside them. I used google’s site specific search (is that the canon way to search swift-evo?) and only found one thread about this,

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

> On Jun 6, 2017, at 12:08 AM, Jens Persson via swift-evolution > wrote: > > IMHO There seems to be a lot of bugs and inconsistencies left in more than > just the reflective type system, for example the following won't compile > although the two foo funcs clearly

Re: [swift-evolution] [Meta] WWDC week

 > On Jun 5, 2017, at 10:53 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On May 30, 2017, at 10:26 PM, Brent Royal-Gordon >> wrote: >> >> I'm going to be in San Jose during WWDC next week, and I'm assuming I won't >> be the

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

IMHO There seems to be a lot of bugs and inconsistencies left in more than just the reflective type system, for example the following won't compile although the two foo funcs clearly take different types as argument: func foo(fun: (Int, Int) -> ()) { print("was given a function of type: (Int,

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md Overall it looks pretty good. But unfortunately the answer to "Will applications still compile but produce