Re: [swift-evolution] Revisiting SE-0110

The “inout” modifier is probably one of the main culprits here. While it is certainly very convenient to use (and I personally use it a lot), its very existence seems to have some downsides that restrict Swift design decisions. Maybe there is a solution though: make “inout” distribute over

Re: [swift-evolution] Revisiting SE-0110

I think the Core Team initially (pre-Swift 1) wanted to make tuples and arguments isomorphic. But that model has many downsides which forced us to backtrack from that model: • Modifiers on arguments (like inout) would force us to introduce them as part of the type-system on tuples, which makes

Re: [swift-evolution] Revisiting SE-0110

>>> >>> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution > wrote: It's probably late to just casually add a couple of cents to a discussion that has been going for so long, but it seems to me

Re: [swift-evolution] Revisiting SE-0110

> On Jun 24, 2017, at 12:25 PM, Djura Retired Hunter > wrote: > > I didn't understand your example at all. Care to elaborate? > > Elviro > >> Il giorno 24 giu 2017, alle ore 18:05, Daryle Walker > > ha scritto: >> >>

Re: [swift-evolution] Revisiting SE-0110

I didn't understand your example at all. Care to elaborate? Elviro > Il giorno 24 giu 2017, alle ore 18:05, Daryle Walker ha > scritto: > > >> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution >> >

Re: [swift-evolution] Revisiting SE-0110

> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution > wrote: > > It's probably late to just casually add a couple of cents to a discussion > that has been going for so long, but it seems to me that from a user > standpoint, that uses types to structure

Re: [swift-evolution] Revisiting SE-0110

Hi, thanks for the answer. >> …by showing code that’s marginally different from each other, like one more >> nesting of parentheses, or one less label for a parameter. It seems to me >> that distinctions like these are just important at the compiler level, but >> not particularly useful from

Re: [swift-evolution] Revisiting SE-0110

Hi Elviro, > On 23. Jun 2017, at 13:46, Elviro Rocca via swift-evolution > wrote: [snip] > …by showing code that’s marginally different from each other, like one more > nesting of parentheses, or one less label for a parameter. It seems to me > that distinctions

Re: [swift-evolution] Revisiting SE-0110

This has been a very hard discussion to follow, even for a programmer that mostly just silently reads these threads to get a general understanding of what's going on in the community. There's an overwhelming amount of messages that point out potential bugs and unexpected behavior by showing

Re: [swift-evolution] Revisiting SE-0110

On Jun 17, 2017, at 9:18 AM, Xiaodi Wu wrote: > Fine by me as well, but to be clear this will be a non-trivial source > breaking change. I understand your desire for caution here, and I completely agree that we don’t want to accidentally break code. As established

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 4:55 PM, Xiaodi Wu wrote: > >>> >>> Agreed, it may be too late to correct this (certainly we can't outright >>> remove it in Swift 4 if someone is using it for something important). >>> However if it turns out that it really isn't used, then

Re: [swift-evolution] Revisiting SE-0110

I can only agree here, the language suffers from shortcuts like that. Same goes for access modifier on extensions, or `indirect` before enums and as already mentioned before me labeled tuple destructuring. --  Adrian Zubarev Sent with Airmail Am 17. Juni 2017 um 18:09:50, Matthew Johnson via

Re: [swift-evolution] Revisiting SE-0110

Sent from my iPad > On Jun 17, 2017, at 10:20 AM, Paul Cantrell via swift-evolution > wrote: > > Yes, agreed, the fix for Chris’s brain-bender shouldn’t revisit any of > SE-0155’s matching & labeling rules. > > How about: > > 1. Disallow labels for bare tuples

Re: [swift-evolution] Revisiting SE-0110

Fine by me as well, but to be clear this will be a non-trivial source breaking change. On Sat, Jun 17, 2017 at 11:09 Matthew Johnson wrote: > > > Sent from my iPad > > On Jun 17, 2017, at 10:20 AM, Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote:

Re: [swift-evolution] Revisiting SE-0110

Yes, agreed, the fix for Chris’s brain-bender shouldn’t revisit any of SE-0155’s matching & labeling rules. How about: 1. Disallow labels for bare tuples in patterns. (By “bare tuples” I mean “not representing associated values on an enum.”) let (a: x, b: y) = foo // disallowed

Re: [swift-evolution] Revisiting SE-0110

See: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html On Fri, Jun 16, 2017 at 22:32 Paul Cantrell wrote: > Under these not-yet-implemented plans, if associated value labels are no > longer tuple labels, then how will pattern matching work?

Re: [swift-evolution] Revisiting SE-0110

Under these not-yet-implemented plans, if associated value labels are no longer tuple labels, then how will pattern matching work? And what existing pattern matching code will break / continue to work? P > On Jun 16, 2017, at 10:22 PM, Xiaodi Wu wrote: > > Keep in mind

Re: [swift-evolution] Revisiting SE-0110

Keep in mind that once the latest proposal about enum cases is implemented, these will be at least notionally no longer tuple labels but rather a sugared way of spelling part of the case name. The rules surrounding labels during case matching have only just been revised and approved and have not

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 5:23 PM, Mark Lacey wrote: > > >> On Jun 16, 2017, at 2:09 PM, Paul Cantrell > > wrote: >> >>> >>> On Jun 16, 2017, at 3:43 PM, Mark Lacey >> >

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 2:09 PM, Paul Cantrell wrote: > >> >> On Jun 16, 2017, at 3:43 PM, Mark Lacey > > wrote: >> >> >>> On Jun 16, 2017, at 1:21 PM, Mark Lacey >> >

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 3:43 PM, Mark Lacey wrote: > > >> On Jun 16, 2017, at 1:21 PM, Mark Lacey > > wrote: >> >>> >>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution >>>

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 1:21 PM, Mark Lacey wrote: > >> >> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution >> > wrote: >> >>> >>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >>>

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution > wrote: > >> >> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> >> On Thu, Jun 15, 2017 at 19:03 Víctor

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution > wrote: > > > On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > wrote: > On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] Revisiting SE-0110

My guess is that core team is planning to accept *patterns* in closure parameter clause. e.g.: let dict = ["foo": 1, "bar": 2] let result = dict.map { ((k, v) : (key: String, value: Int)) in ... } ^^ pattern When the compiler see this expression: dict.map {

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 08:04, Xiaodi Wu wrote: > >> On Fri, Jun 16, 2017 at 12:17 AM, David Hart wrote: >> >> >>> On 16 Jun 2017, at 01:55, Xiaodi Wu wrote: >>> >>> On Thu, Jun 15, 2017 at 17:43 David Hart

Re: [swift-evolution] Revisiting SE-0110

It seems to me that we have a general problem with labels and every time we have to push things around they break and we simply rip them out: first with argument labels in closures and stores functions (sigh... :/, but we may get labels back somehow there one day not too far from now hopefully)

Re: [swift-evolution] Revisiting SE-0110

On Fri, Jun 16, 2017 at 12:17 AM, David Hart wrote: > > > On 16 Jun 2017, at 01:55, Xiaodi Wu wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: > >> On 16 Jun 2017, at 00:41, David Hart wrote: >> >> >> On

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 01:55, Xiaodi Wu wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: On 16 Jun 2017, at 00:41, David Hart wrote: On 15 Jun 2017, at 19:28, Chris Lattner wrote:

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel wrote: > On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: > >> On 16 Jun 2017, at 00:41, David Hart

Re: [swift-evolution] Revisiting SE-0110

> On 15 Jun 2017, at 06:01, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: >> >> What’s the status of this Chris’s double parens idea below? It garnered some >> positive responses, but the

Re: [swift-evolution] Revisiting SE-0110

On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: On 16 Jun 2017, at 00:41, David Hart wrote: On 15 Jun 2017, at 19:28, Chris Lattner

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 15, 2017 at 17:43 David Hart wrote: > On 16 Jun 2017, at 00:41, David Hart wrote: > > > On 15 Jun 2017, at 19:28, Chris Lattner wrote: > > > On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution < >

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 10:28 AM, Chris Lattner via swift-evolution > wrote: > > My belief on this is that it is a legacy Swift 1 type system capability that > no one uses. I have no data to show that though. Tangential and perhaps a terrible idea, but: It's 2017.

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 00:41, David Hart wrote: > > >> On 15 Jun 2017, at 19:28, Chris Lattner > > wrote: >> >> >> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] Revisiting SE-0110

> On 15 Jun 2017, at 19:28, Chris Lattner wrote: > > > On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution > > o >>> > >>> > let (a : Int, b : Float) = foo() >>> >>> >>> I think it would be better if the

Re: [swift-evolution] Revisiting SE-0110

It’s not just a syntactic thing we’re talking about here. The grammar permits all kinds of wonky combinations of things that will parse as “TSPL Swift", but will fail in Sema. In that sense, no, this feature is not documented there. ~Robert Widmann > On Jun 15, 2017, at 12:08 PM, Kyle Murray

Re: [swift-evolution] Revisiting SE-0110

Yes, in the sense that the grammar has a production that permits the tuple element name. But there aren't any examples that use labels

Re: [swift-evolution] Revisiting SE-0110

> > On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution > o > > let (a : Int, b : Float) = foo() I think it would be better if the compiler raised a warning whenever you tried to redefine a builtin type. >>> >>> That’s

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 10:28 AM, Chris Lattner wrote: > > >> Is the feature harmful? > > Yes, absolutely. The shadowing isn't the thing that bothers me, it is that > swift has a meaning for that very syntax in other contexts, and that this is > completely different

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 8:23 AM, Robert Bennett via swift-evolution > wrote: > >> One (tangential) thing that came up is that tuple element names in tuple >> *patterns* should probably be deprecated and removed at some point. Without >> looking, what variables does

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 15, 2017 at 11:19 David Hart wrote: > On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution < > swift-evolution@swift.org> wrote: > >> > One

Re: [swift-evolution] Revisiting SE-0110

> On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution > > wrote: > > One (tangential) thing that came up is that tuple

Re: [swift-evolution] Revisiting SE-0110

Let me clarify: I'm only talking about removing tuple element names from the *pattern* grammar. They would still be allowed on tuple types, which is what you are using. -Chris > On Jun 14, 2017, at 9:45 PM, Charlie Monroe wrote: > > >> On Jun 15, 2017, at 6:01

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > > One (tangential) thing that came up is that tuple element names in tuple > *patterns* should probably be deprecated and removed at some point. > Without looking, what variables does this

Re: [swift-evolution] Revisiting SE-0110

> One (tangential) thing that came up is that tuple element names in tuple > *patterns* should probably be deprecated and removed at some point. Without > looking, what variables does this declare?: > > let (a : Int, b : Float) = foo() I think it would be better if the compiler raised a

Re: [swift-evolution] Revisiting SE-0110

Sent from my iPad > On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: >> >> What’s the status of this Chris’s double parens idea below? It garnered some >>

Re: [swift-evolution] Revisiting SE-0110

It declares variables Int and Float, but I know that only because CodaFi asked us the same question on twitter a while back! I'd be very happy if that was deprecated. > On 15 Jun 2017, at 06:01, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 6:01 AM, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: >> >> What’s the status of this Chris’s double parens idea below? It garnered some >> positive responses, but

Re: [swift-evolution] Revisiting SE-0110

> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: > > What’s the status of this Chris’s double parens idea below? It garnered some > positive responses, but the discussion seems to have fizzled out. Is there > something needed to help nudge this along? > > What’s the

Re: [swift-evolution] Revisiting SE-0110

What’s the status of this Chris’s double parens idea below? It garnered some positive responses, but the discussion seems to have fizzled out. Is there something needed to help nudge this along? What’s the likelihood of getting this fixed before Swift 4 goes live, and the great wave of

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

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

Re: [swift-evolution] Revisiting SE-0110

Wait, there's more! > When passing a closure with a single underscore argument ({ _ in ...}) to a > function expecting multiple arguments, the compiler may error after migration > with: > > error: cannot convert value of type '(_) -> ()' to expected argument > type > (32301091) >

Re: [swift-evolution] Revisiting SE-0110

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 with the closure types that are passed

Re: [swift-evolution] Revisiting SE-0110

Yes, double parenthesis for tuple argument destructuring in closure was discussed in this thread, and I feel it is one of the best options. But the main question I can't find the clear answer for, what will be with function/closure types in Swift 4. IMO *this* is the main question, not the

Re: [swift-evolution] Revisiting SE-0110

On Mon, Jun 5, 2017 at 9:31 AM, Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > The motivation section is not at all about any "type checker problem". > It's about a postulate that has been proven horribly source-breaking, and > counter-productive. The type safety argument

Re: [swift-evolution] Revisiting SE-0110

> Le 4 juin 2017 à 19:16, Chris Lattner via swift-evolution > a écrit : > > One way to split the difference here is to eliminate the splatting behavior, > but keep the destructuring (irrefutable pattern matching) behavior as well. > In these cases, just require an

Re: [swift-evolution] Revisiting SE-0110

2017-06-05 2:16 GMT+09:00 Chris Lattner via swift-evolution < swift-evolution@swift.org>: > > On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic wrote: > > On Thu, Jun 1, 2017 at 8:52

Re: [swift-evolution] Revisiting SE-0110

> One way to split the difference here is to eliminate the splatting behavior, > but keep the destructuring (irrefutable pattern matching) behavior as well. A hearty +1 to this, regardless of the choice of syntax. P > On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution >

Re: [swift-evolution] Revisiting SE-0110

Sent from my iPad > On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution > wrote: > > >>> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution >>> wrote: >>> >>> >>> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic

Re: [swift-evolution] Revisiting SE-0110

> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution > wrote: > > >> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic > > wrote: >> >> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution >>

Re: [swift-evolution] Revisiting SE-0110

I like the idea of the case let syntax option except for the fact that we have existing syntax for decomposing tuples that doesn’t use case- let (_, age) = arg Reusing this syntax feels like a better option than introducing a slight variant of it just for closures- let eighteenOrMore =

Re: [swift-evolution] Revisiting SE-0110

Thanks, added. On Friday, June 2, 2017 1:18 PM, Vladimir.S wrote: On 02.06.2017 2:34, Tommaso Piazza wrote: > Is the version you suggest to add to my list for the Swift syntax currently > valid as > of SE-0110 in Swift 4? Yes, just checked on latest dev snapshot of

Re: [swift-evolution] Revisiting SE-0110

John and others, who are involved into this thread. I'd suggest to clarify the current(Swift4) situation with function/closure type before we make any other decision and before continue to discuss the subject. (sorry for long email, but I feel the problem with SE-0110 is wider than just "let's

Re: [swift-evolution] Revisiting SE-0110

On 02.06.2017 2:34, Tommaso Piazza wrote: Is the version you suggest to add to my list for the Swift syntax currently valid as of SE-0110 in Swift 4? Yes, just checked on latest dev snapshot of Swift 4. On Thursday, June 1, 2017 9:32 PM, Vladimir.S wrote: On 01.06.2017

Re: [swift-evolution] Revisiting SE-0110

On Fri, Jun 2, 2017 at 1:53 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > I vote to revert it to current behavior. Then we can take time to come up > with the correct answer for future Swift. > > If we don’t revert and then end up changing it again later, we will

Re: [swift-evolution] Revisiting SE-0110

On Fri, Jun 2, 2017 at 12:06 AM, John McCall wrote: > > You're misunderstanding me. I have explicitly said, several times, that I > agree that the impact on tuple destructuring in closures is a serious > regression. There have *also* been objections to losing argument-splat

Re: [swift-evolution] Revisiting SE-0110

I vote to revert it to current behavior. Then we can take time to come up with the correct answer for future Swift. If we don’t revert and then end up changing it again later, we will break everybody’s code twice... Thanks, Jon > On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic via

Re: [swift-evolution] Revisiting SE-0110

Is the version you suggest to add to my list for the Swift syntax currently valid as of SE-0110 in Swift 4? On Thursday, June 1, 2017 9:32 PM, Vladimir.S wrote: On 01.06.2017 19:31, Tommaso Piazza wrote: > Dear all, > > I made a comparison of Swift's 4 lack of tuple

Re: [swift-evolution] Revisiting SE-0110

> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic wrote: > > On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution > > wrote: > > I understand that there are developers who dislike SE-0110's impact on > certain

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > I understand that there are developers who dislike SE-0110's impact on > certain kinds of functional programming, but that is a very broad complaint > that is unlikely to reach consensus or

Re: [swift-evolution] Revisiting SE-0110

To add more real-world project data to this discussion, I just did a test migration of Siesta to Swift 4 using the 2017-05-30 snapshot. Nothing earth-shattering follows — just more practical evidence that the problem needs attention. Here’s what I found: (1) The lack of tuple destructing

Re: [swift-evolution] Revisiting SE-0110

On 01.06.2017 21:52, John McCall wrote: On Jun 1, 2017, at 3:25 AM, Vladimir.S wrote: On 01.06.2017 0:42, John McCall wrote: On May 31, 2017, at 2:02 PM, Stephen Celis wrote: On May 28, 2017, at 7:04 PM, John McCall via swift-evolution

Re: [swift-evolution] Revisiting SE-0110

On 01.06.2017 22:46, T.J. Usiyan wrote: I, for one, would be willing to accept Xiaodi's suggestion involving `let`–especially if (pipe dream follows) we could use the same syntax in functions/methods to destructure parameters. Yes, Xiaodi's suggestion also was very attractive. Just to remind:

Re: [swift-evolution] Revisiting SE-0110

I, for one, would be willing to accept Xiaodi's suggestion involving `let`–especially if (pipe dream follows) we could use the same syntax in functions/methods to destructure parameters. On Thu, Jun 1, 2017 at 3:32 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On

Re: [swift-evolution] Revisiting SE-0110

On 01.06.2017 19:31, Tommaso Piazza wrote: Dear all, I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it stands in comparison with other languages https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935 Thank you! Very useful information. And also I really

Re: [swift-evolution] Revisiting SE-0110

> On Jun 1, 2017, at 3:25 AM, Vladimir.S wrote: > > On 01.06.2017 0:42, John McCall wrote: >>> On May 31, 2017, at 2:02 PM, Stephen Celis wrote: On May 28, 2017, at 7:04 PM, John McCall via swift-evolution wrote:

Re: [swift-evolution] Revisiting SE-0110

> On 1 Jun 2017, at 17:31, Tommaso Piazza via swift-evolution > wrote: > > >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution > >>> > wrote: > >>> > >>> Yes, I agree. We need to add back

Re: [swift-evolution] Revisiting SE-0110

Dear all, I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it stands in comparison with other languages  https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935 On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution

Re: [swift-evolution] Revisiting SE-0110

> On May 31, 2017, at 3:53 PM, John McCall wrote: > >> On May 31, 2017, at 3:42 PM, Tony Parker > > wrote: >>> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution >>>

Re: [swift-evolution] Revisiting SE-0110

> On May 31, 2017, at 3:42 PM, Tony Parker wrote: >> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution >> > wrote: >> >>> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution

Re: [swift-evolution] Revisiting SE-0110

> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution > wrote: > >> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution >> > wrote: >> On Mon, May 29, 2017 at 10:47 PM,

Re: [swift-evolution] Revisiting SE-0110

> On May 31, 2017, at 2:02 PM, Stephen Celis wrote: >> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution >> wrote: >> >> Yes, I agree. We need to add back tuple destructuring in closure parameter >> lists because this is a

Re: [swift-evolution] Revisiting SE-0110

Seeing this makes me rethink the severity of this problem. I wonder if it would be worth it to add a starMap function that works like map, but unpacks tuples into separate arguments. So dict.map { (key, value) in ... } is still illegal but dict.starMap { (key, value) in ... } works like

  1   2   >