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

On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > Just a thought > > if parentheses is important, why the tuples are not? > This is stated on the proposal (and not in previous proposals):

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

Also, I want to repeat what I said on the other thread. We should revert to Swift 3 behavior for this, and then take the time to design the behavior we really want (either for 4.1 or 5). Anything else will cause us to break people’s code twice… Thanks, Jon > On Jun 7, 2017, at 11:50 AM,

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

> On Jun 7, 2017, at 11:33 AM, Gwendal Roué via swift-evolution > wrote: > > So far, the answer to the ergonomics regression reports have been much too > often negative. I wish ergonomics had better support in the community. Very > few regular developers talk here,

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

Ah, quite ingenious, Susan! And you made me realize that the only reason my no-operator-needed code didn’t compile is that I had keypath instead of keyPath. So it was indeed “Paul needs to go to sleep now” option, which I will now do.  P > On Jun 7, 2017, at 11:34 PM, Susan Cheng

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution > wrote: > > 1. Arbitrary `self` Assignments In Intializers > > The first ideas is to allow `self = nil` inside failable initializers > (essentially making `self` look like `inout Self?` instead of

Re: [swift-evolution] Introduction of OrderedSet

I would be in favor of it; there have been a few times (including Core Data, as you mentioned) where I would have used it had it been available. Jeff Kelley slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org > On Jun 7, 2017, at

Re: [swift-evolution] Int indexing into UTF16View

> On 8 Jun 2017, at 14:11, Xiaodi Wu wrote: > > At some point–although it’s unclear if it’s still the case after the recent > String revisions–it was the case that Foundation extended String to allow > integer subscripting of UTF16View. > > The issue with offering it

Re: [swift-evolution] Int indexing into UTF16View

> On 8 Jun 2017, at 14:15, Vladimir.S wrote: > >> On 08.06.2017 20:32, David Hart via swift-evolution wrote: >> Hello, >> When working with Strings which are known to be ASCII, I tend to use the >> UTF16View for the performance of random access. > > About the performance.

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

On 09.06.2017 4:02, susan.dog...@gmail.com wrote: Vladimir.S via swift-evolution 於 2017年6月9日 上午5:05 寫道： On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

 > On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution > wrote: > > The new smart key path feature is really lovely, and feels like a great > addition to Swift. > > It seems like it might be straightforward to add overloads of `map` and > `flatMap` to the

[swift-evolution] Introduction of OrderedSet

Hello, in the past there have been a few requests for an OrderedSet implementation in Swift. In the proposal https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md was mentioned that the OrderedSet will be considered for the feature. However,

[swift-evolution] Pitch: Limit typealias extensions to the typealias

Typealiases can greatly reduce the complexity of code. But I think one change in how the compiler handles them could make them even more powerful. Let's say I'm creating a web server framework and I've created a simple dictionary to store HTTP headers (I know that headers are more complex than

[swift-evolution] Pitch: Documentation access from the Swift REPL

I am new to Swift and just started learning but... When exploring standard library and the language it self from the REPL. Users currently need to switch between a browser to read documentation and the REPL it self. What I would like to see in the REPL is behaviour like this: 1> :help print

[swift-evolution] [Proposal] Uniform Initialization Syntax

Disclaimer: I do realize that any of the following ideas may have been discussed before and/or there might be a good reason for their lack of implementation, so please go easy in me.  1. Arbitrary `self` Assignments In Intializers The first ideas is to allow `self = nil` inside failable

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

Xiaodi, I'm interested in your opinion, don't you think that *SE-0066* was the main proposal that separated (Int,Int)->() and ((Int,Int))->() function *types*? (https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md) 'Proposed solution' section

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

On 08.06.2017 9:43, Jonathan Hull wrote: Also, I want to repeat what I said on the other thread. We should revert to Swift 3 behavior for this, and then take the time to design the behavior we really want (either for 4.1 or 5). Anything else will cause us to break people’s code twice… Yes,

[swift-evolution] Pitch: Support for map and flatMap with smart key paths

I had the need for the same thing today and made it as an extension on Sequence. extension Sequence { func map(_ keyPath: KeyPath) -> [T] { return self.map { $0[keyPath: keyPath] } } func flatMap(_ keyPath: KeyPath) -> [T] {

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> On Jun 8, 2017, at 05:09, Gor Gyolchanyan via swift-evolution > wrote: > > Disclaimer: I do realize that any of the following ideas may have been > discussed before and/or there might be a good reason for their lack of > implementation, so please go easy in me. 

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Could you please elaborate why #1 and #3 would violate the rule? About #1: Currently, before all members are initialized, attempts to call to `super.init` or escape `self` will be met with a compile-time error. The idea behind `self = nil` is to mark the initializer as `going to fail on

[swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

I've just been trying out the new Coding protocol, and was rather surprised when trying to implement the `encode(to encoder: Encoder)` method. The Swift evolution proposal provides the following example code: public func encode(to encoder: Encoder) throws { // Generic keyed encoder

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

On Thu, Jun 8, 2017 at 7:53 AM, Vladimir.S wrote: > Xiaodi, I'm interested in your opinion, don't you think that *SE-0066* was > the main proposal that separated (Int,Int)->() and ((Int,Int))->() function > *types*? > (https://github.com/apple/swift-evolution/blob/master/propos

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

On 08.06.2017 12:17, Víctor Pimentel Rodríguez via swift-evolution wrote: On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution > wrote: Just a thought if parentheses is important, why the tuples are not? This is

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

Hi James, Good catch. This is a holdover from an older version of the proposal, and is now a typo. It should be `var container` — the container can be a `struct`, and shouldn’t require reference semantics. — Itai On 8 Jun 2017, at 7:51, James Froggatt via swift-evolution wrote: I've just

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution > wrote: >> >> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution >> a écrit : >> >> Here, container is stored as a `let` value, and uses reference semantics, >>

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

I just want to say, as a "regular developer", that I'm with Vladimir S here. Swift 3 (and current Swift 4) both still have a lot of inconsistencies and/or bugs related to tuple- and function types which will need to be fixed before ABI stability, and they are not fixed by going back to a state

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

> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution > a écrit : > >> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution >> > wrote: >> >> Well please no: >> >> 
>> let fn2:

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

> Le 8 juin 2017 à 20:17, Gwendal Roué a écrit : > > This gives us the ability to deal with unfitted function signatures. For > example, most Dictionary methods. Yes, they are usually unfitted: > > extension Dictionary { > func forEach(_ body: ((key: Key,

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

At first glance, this makes totally sense to me, feel free to push this idea on the main discussion thread about this dilemma. :) --  Adrian Zubarev Sent with Airmail Am 8. Juni 2017 um 19:41:03, Brent Royal-Gordon (br...@architechies.com) schrieb: On Jun 7, 2017, at 3:03 AM, Adrian Zubarev

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

> On 8 Jun 2017, at 11:17, Gwendal Roué via swift-evolution > wrote: > > >> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution >> > a écrit : >> >>> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

> On 8 Jun 2017, at 17:48, Brent Royal-Gordon wrote: > >> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution >> > wrote: >>> >>> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution >>>

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

> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution > a écrit : > >> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution >> > wrote: >> >> Well please no: >> >> 
>> let fn2:

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Yeah, it's just a small syntactic sugar that doesn't change the current behavior at all, it merely makes initialization syntax more uniform and consistent. Also, something just occurred to me: When we're dealing with convenience initializers, there's the syntax `self.init(...)`, wouldn't it

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

To clarify further about DefaultInitializable: An uninitialized variable of a DefaultInitializable type will *only* have its `init()` called if it's accessed before being initialized manually. This will ensure that the variable will never be initialized twice. > On Jun 8, 2017, at 6:20 PM,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Isn’t 1 und 2.1 almost the same stuff? I’ve asked once if there is a chance for Swift to support init(_ other: Self) { self = other } for classes. Joe Groff replied this is called “factory initializer”. This feature is highly needed for all the iOS developers out there who abuse NIBs and

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Well I was referring to the title of (1) not to the addition it creates with failable initializers, which I guess is fine by me, but I’d need a more detailed proposal or draft to provide better feedback though. --  Adrian Zubarev Sent with Airmail Am 8. Juni 2017 um 17:51:28, Gor Gyolchanyan

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> On Jun 8, 2017, at 9:19 AM, David Sweeris via swift-evolution > wrote: > > #1 & #3 would violate Swift's rule about having to fully initialize all > properties in inits. > > My initial reaction is to like #2, though, assuming I understand it correctly. Assigning

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

The problem is, it's not clear what assumptions the swift compiler may have on the semantics of initializers. There may be aggressive optimizations going on under the hood with the knowledge that the returned type is the static type that is being initialized. This guaranteed lack of

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution > a écrit : > > I've just been trying out the new Coding protocol, and was rather surprised > when trying to implement the `encode(to encoder: Encoder)` method. > > The Swift evolution proposal provides

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Not exactly. #1 is an addition to the language syntax. It's simply a convenient way of expressing failure in a failable initializer the logic of which is already implemented, while extending the syntax in a way that would require zero effort to enable a potential factory initializers. > On Jun

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

On Thu, Jun 8, 2017 at 3:01 PM, Vladimir.S wrote: > On 08.06.2017 12:17, Víctor Pimentel Rodríguez via swift-evolution wrote: > >> On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution < >> swift-evolution@swift.org > wrote: >> >>

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

> On Jun 8, 2017, at 9:45 AM, Itai Ferber > wrote: > > Hi Gwendal, > >> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution >> > wrote: >> >>> >>> Le 8 juin 2017 à 16:51,

[swift-evolution] Int indexing into UTF16View

Hello, When working with Strings which are known to be ASCII, I tend to use the UTF16View for the performance of random access. I would also like to have the convenience of indexing with Int: let barcode = "M1X/CLEMENT EELT9QBQGVAAMSEZY1353 244 21D 531 10A1311446838” let name =

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

On Thu, Jun 8, 2017 at 7:20 PM, Víctor Pimentel Rodríguez via swift-evolution wrote: > > /../ I'm really going to miss being able to model every type of closure > with the type (T) -> U > Me too, and I can also see what you mean regarding the "tone" of some of the

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

Sorry, meant for that to be a reply-all. > On Jun 8, 2017, at 9:45 AM, Itai Ferber wrote: > > Hi Gwendal, > >> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution >> > wrote: >> >>> >>> Le 8 juin 2017 à

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

> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution > wrote: > > Well please no: > > 
> let fn2: ((Int, Int)) -> Void = { lhs, rhs in } > > Instead use destructuring sugar pitched by Chris Lattner on the other thread: > > let fn2: ((Int, Int)) ->

Re: [swift-evolution] Int indexing into UTF16View

> On 8 Jun 2017, at 12:35, Tony Allevato wrote: > > It is an extremely rare case for a developer to know a priori what literal > numeric indices should be used when indexing into a string, because it only > applies when strings fall into a very specific format and

Re: [swift-evolution] Int indexing into UTF16View

It is an extremely rare case for a developer to know a priori what literal numeric indices should be used when indexing into a string, because it only applies when strings fall into a very specific format and encoding. It's been discussed before during String-related proposals but AFAIK the core

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

Side note: when converting a project to Swift 4, I’ve encountered quite a few Quality of Life regressions that could also be related: Regression 1 When using this library https://github.com/socketio/socket.io-client-swift: public typealias NormalCallback = ([Any], SocketAckEmitter) -> Void

[swift-evolution] Fortran arrays and my recent proposal

My array proposals included some form of specifying storage ranks for each extent. By default, the ranks would follow row-major order, like C. The first dimension would have the widest span between elements that differ by 1 in the first index and are the same for other indexes. The last

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

As a "regular user" I wholeheartedly agree with everything Robert just said. Syntactic consistency between function parameters and closure parameters is a big win for usability and discoverability. I actually did not know that it was possible to destructure tuples in closure arguments before

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

On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution > a écrit : On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution

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

I’m personally a fan of strictness and maximum consistency. I like the idea of flattening single element tuples down to the deepest thing contained that is not a single element tuple. So (x) flattens to x and x,y flattens to the tuple (x,y). Past SEs have dictated that you may not

Re: [swift-evolution] Int indexing into UTF16View

On 08.06.2017 20:32, David Hart via swift-evolution wrote: Hello, When working with Strings which are known to be ASCII, I tend to use the UTF16View for the performance of random access. About the performance. Do we have a guarantee that 'barcode' declared in code and/or containing only

Re: [swift-evolution] Int indexing into UTF16View

At some point–although it’s unclear if it’s still the case after the recent String revisions–it was the case that Foundation extended String to allow integer subscripting of UTF16View. The issue with offering it generally is that it doesn’t reliably serve any use case. You’re using it for

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

On 08.06.2017 20:40, Brent Royal-Gordon via swift-evolution wrote: On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution > wrote: Well please no: 
|let fn2: ((Int, Int)) -> Void = { lhs, rhs in }| Instead use destructuring

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

> On Jun 7, 2017, at 11:12 PM, Stephen Celis via swift-evolution > wrote: > >> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> However, what I don’t get is why you’d have a mismatch here. Your method >>

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

> On Jun 8, 2017, at 2:05 PM, Vladimir.S via swift-evolution > wrote: > > On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: >>> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution >>>

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

On 09.06.2017 0:31, Mark Lacey wrote: On Jun 8, 2017, at 2:05 PM, Vladimir.S via swift-evolution > wrote: On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution