[swift-evolution] Fwd: Re: Smart KeyPaths

On 20.03.2017 17:56, Charles Srstka via swift-evolution wrote: On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution mailto:swift-evolution@swift.org>> wrote: On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 20 Mar 2017,

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md * What is your evaluation of the proposal? -1. As was mentione

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 6:01, Ricardo Parada via swift-evolution wrote: Sometimes I feel like we need a winning sigil for this, one that would look good, it is not already taken and easy to type in all keyboards. Maybe we'll have to start looking at emojis :-) IMO syntax for method references should ma

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 17:37, Ricardo Parada wrote: On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: let path = @Bag.things[0].name bag@path bag@.things[0].name bag@Bag.things[0].name bag.things[0]@.name bag.things[0]@Thing.name It sounds like the @ character is serving two different purposes which

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 18:47, Matthew Johnson wrote: On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 22.03.2017 17:37, Ricardo Parada wrote: On Mar 22, 2017, at 9:30 AM, Vladimir.S mailto:sva...@gmail.com>> wrote: let path = @

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 19:25, Matthew Johnson wrote: On Mar 22, 2017, at 11:00 AM, Vladimir.S mailto:sva...@gmail.com>> wrote: On 22.03.2017 18:47, Matthew Johnson wrote: On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org> <mailto:swift-evoluti

Re: [swift-evolution] Pitch: Partial Implementations

On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote: On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution wrote: MOTIVATION: In current Swift, a pattern has emerged among some developers, in order to logically group parts of a class or struct’s declaration, particularly

Re: [swift-evolution] Pitch: Partial Implementations

On 24.03.2017 12:50, Haravikk wrote: On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote: On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution mailto:swift-evo

Re: [swift-evolution] Pitch: Partial Implementations

in problem you are trying to solve in current proposal. IMO It is obvious that current proposal "as it is" will not be supported. On 24 March 2017 at 15:20, Haravikk via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 23 Mar 2017, at 21:10, Vlad

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On 24.03.2017 11:47, Jonathan Hull via swift-evolution wrote: Nevin had a fantastic proposal for submodules which changed private to mean “private to the submodule”, where each file was implicitly a submodule unless you declared otherwise. Simple and elegant. Currently I don't see how submodul

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

level" camp. On Fri, Mar 24, 2017 at 1:49 PM, Ricardo Parada via swift-evolution mailto:swift-evolution@swift.org>> wrote: After reading the discussions it seems to me that renaming private -> scoped and fileprivate -> private might keep both sides happy. > On Ma

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

On 27.03.2017 20:00, Ross O'Brien via swift-evolution wrote: I'm considering this from a different angle. When we declare a type, we declare properties and functions which that type has. When we extend a type, we add functions to the type. (I'm including computed properties in this.) It's become

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

x27;s access level) internal var n = 100 // internal public var o = 110 // public->internal(type's access level) } } Do you see any drawbacks in such design? (given that we disallow scoped access modifier at top level of file and for nested extensions in type) On Mon,

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

(type's access level) internal var n = 100 // internal public var o = 110 // public->internal(type's access level) } } Do you see any drawbacks in such design? (given that we disallow scoped access modifier at top level of file and for nested extensions in type) On Mon, Mar 27, 2

[swift-evolution] [Pitch] Nested extensions and stored properties

{ scoped var l = 80 // scoped for extension, inaccessible outside of it var m = 90 // public -> internal(type's access level) internal var n = 100 // internal public var o = 110 // public->internal(type's access level) } } Do you see any drawbacks in such des

Re: [swift-evolution] Smart KeyPaths

On 30.03.2017 16:12, Matthew Johnson via swift-evolution wrote: Sent from my iPad On Mar 30, 2017, at 12:35 AM, David Hart via swift-evolution mailto:swift-evolution@swift.org>> wrote: Sent from my iPhone On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution mailto:swift-evol

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

On 01.04.2017 9:17, Richard Wei via swift-evolution wrote: I agree. But I don’t think the predicate needs an argument label. `membersSatisfy(_:)` or `forAll(_:)` sounds better. checkAll(areEqualTo:) ? -Richard On Mar 31, 2017, at 23:02, Will Stanton via swift-evolution wrote: +1 to add

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

On 01.04.2017 10:50, Brandon Trussell via swift-evolution wrote: I agree that based on the method name, I thought a collection would be returned. From the other side, for example C# has the similar IEnumerable.All() method which "Determines whether all elements of a sequence satisfy a conditi

Re: [swift-evolution] (Pitch) Conformance Regions

On 30.03.2017 21:13, Félix Cloutier via swift-evolution wrote: What will you do if you want to privately adopt two protocols that require identical members? I believe the same thing we do currently: conform to both protocols in the same declaration(like class C: P1, P2 {...}) or conform to se

Re: [swift-evolution] multi-line string literals.

On 03.04.2017 19:58, Peter Dillinger via swift-evolution wrote: Can we try to enumerate the potential hazards and potential useful features associated with multi-line strings? Then perhaps you can judge various proposals based on them. Potential hazards: H1) Forgotten '+' (plus). This affe

Re: [swift-evolution] Type-based ‘private’ access within a file

On 03.04.2017 23:13, Matthew Johnson via swift-evolution wrote: On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution mailto:swift-evolution@swift.org>> wrote: I’m concerned that we will have access control changes in a future version yet again, when light-weight modules, or other type o

Re: [swift-evolution] Type-based ‘private’ access within a file

On 04.04.2017 0:59, Brent Royal-Gordon wrote: On Apr 3, 2017, at 2:54 PM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: Moreover, I think that we need *additional* access level(to current 'private'), which will mean 'can be accessed from extension

Re: [swift-evolution] Type-based ‘private’ access within a file

On 04.04.2017 5:03, BJ Homer via swift-evolution wrote: This type-and-file-based proposal addresses most of the *pragmatic* issues people run into when writing Swift, but I agree with other comments that it's a difficult mental model. It sounds like most everyone likes the idea of renaming "priv

Re: [swift-evolution] Type-based ‘private’ access within a file

On 05.04.2017 7:02, Chris Lattner via swift-evolution wrote: On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution mailto:swift-evolution@swift.org>> wrote: Hello Swift Community, In rejecting SE-0159

Re: [swift-evolution] Type-based ‘private’ access within a file

On 05.04.2017 18:21, Chris Lattner wrote: On Apr 5, 2017, at 4:31 AM, Vladimir.S mailto:sva...@gmail.com>> wrote: From a pragmatic perspective, I feel like this is a great solution that really does solve the problems we have with current access control, all without breaking source compatibility

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

On 06.04.2017 18:10, Ricardo Parada via swift-evolution wrote: I did not mention single quotes because I was assuming those were reserved for string literals. But if they are available for something like this, it would make it obvious where the key path begins and where it ends. I went through

Re: [swift-evolution] Type-based ‘private’ access within a file

On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote: Hi, -evolution. I’ve said this before, but *I think this new proposal is a terrible idea*. It privileges types in a way that is damaging to the language. [There isn't really anything new in my discussion below; everyone on-thread is sma

Re: [swift-evolution] Type-based ‘private’ access within a file

On 06.04.2017 21:17, Jordan Rose wrote: On Apr 6, 2017, at 11:10, Vladimir.S wrote: On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote: Hi, -evolution. I’ve said this before, but *I think this new proposal is a terrible idea*. It privileges types in a way that is damaging to the lang

Re: [swift-evolution] Type-based ‘private’ access within a file

On 06.04.2017 21:40, Jordan Rose via swift-evolution wrote: On Apr 6, 2017, at 11:35, Nevin Brackett-Rozinsky via swift-evolution mailto:swift-evolution@swift.org>> wrote: On Thu, Apr 6, 2017 at 2:17 PM, Jordan Rose via swift-evolution mailto:swift-evolution@swift.org>> wrote: We accept

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 06.04.2017 22:35, Joe Groff via swift-evolution wrote: Hello Swift community, The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-str

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

If you don't want to resolve the mistake of SE-0025 by proposing a really solution but not a workaround, then just leave the things where they are currently. Proposed "improvement" IMO is more confusing than helping. Sorry, I don't buy <<..most of those proposals are not in scope for discussio

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote: Hi all, In a discussion about inferring parameter types from default value, Slava brought up some performance problems caused by type inference for stored properties in side types: https://lists.swift.org/pipermail/swift-evolution/Week

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

On 07.04.2017 16:56, Shawn Erickson via swift-evolution wrote: -1 (strongish) on this proposal for the reason I comment earlier in the discussion thread. This weakens private for not an atypical use case of private that I currently have. It muddies the water between fileprivate and private makin

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

On 11.04.2017 1:51, Xiaodi Wu via swift-evolution wrote: > On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > In response to Jordan Rose's comment I suggest the following change: > > Proposal: Split extension usage up into imp

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 11.04.2017 16:35, John Holdsworth via swift-evolution wrote: I feel discussion on this proposal is nearing general agreement that while the gist of it it seems reasonable to many there is also not enough detail in it as submitted. Brent has person-fully stepped in and rewritten the draft to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

On 11.04.2017 19:47, Jose Cheyo Jimenez via swift-evolution wrote: On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution mailto:swift-evolution@swift.org>> wrote: Strong -1. This is a source breaking change, but Swift 4 stage 2 is already over. I agree with you here. I don't think t

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

On 12.04.2017 7:19, Jaden Geller wrote: On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote: Hi all, In a discussion about inferring parameter types from default value, Slava b

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 12.04.2017 13:16, Thorsten Seitz via swift-evolution wrote: Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via swift-evolution mailto:swift-evolution@swift.org>>: Great explanation thank you Brent. I’m convinced about the closing delimiter now. =) ---

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

Plus, if we *want* we can suggest a way to silence such warning even for retroactive conformance. The question if the problem worth to be solved. On Wed, Apr 12, 2017 at 05:15 Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 12.04.2017 7:19, Jaden Gell

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

a compromise. Such a model has everything we’ve asked for, it’s easy, it has both leading and trailing precision and implicit new lines where needed. -- Adrian Zubarev Sent with Airmail Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 12.04.2017 17:52, Thorsten Seitz via swift-evolution wrote: Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution : Hey folks, We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no lon

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 12.04.2017 22:07, John Holdsworth via swift-evolution wrote: Finally.. a new Xcode toolchain is available largely in sync with the proposal as is. (You need to restart Xcode after selecting the toolchain to restart SourceKit) I

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 13.04.2017 15:41, Brent Royal-Gordon via swift-evolution wrote: On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution mailto:swift-evolution@swift.org>> wrote: Take a look at Brent's revised proposal.I personally thin it is perfect. Take a look: https://github.com/johnno1962a/sw

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 16.04.2017 0:22, Adrian Zubarev via swift-evolution wrote: Hi guys, I am, and also my English is, at my most limit fighting in this conversation. ;-) I would not support, v1 v2 and v3 at all and would wish these options to be completely banned for a nice and simple model, even if all of the

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

On 19.04.2017 23:03, Joe Groff via swift-evolution wrote: Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md Hello Swift Community, The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is *a

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

On 02.05.2017 8:17, Gor Gyolchanyan via swift-evolution wrote: One major thing to keep in mind is how exactly will it behave in generic contexts. As a similar example, if you can do this: func foo(pass parameter: A, to closure: (A) -> B) -> B { closure(parameter) } func bar(one: Int, two: Doub

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote: I can't think of a single time when I would need a tuple shuffle but I don't really work with tuples much. It would be great to hear other people's usage of this feature. I did not know that types could be overloaded with values.

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

On 05.05.2017 19:38, Jose Cheyo Jimenez wrote: On May 5, 2017, at 8:34 AM, Vladimir.S mailto:sva...@gmail.com>> wrote: On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote: I can't think of a single time when I would need a tuple shuffle but I don't really work with tuples much.

Re: [swift-evolution] Revisiting SE-0110

Regarding the requiring of parentheses for arguments in closures: I'd suggest to look into SE-0066's paragraph "Should we require parentheses in closure expression parameter lists?" and "Rationale" for this SE: https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000138.html (SE-0

Re: [swift-evolution] Revisiting SE-0110

On 29.05.2017 18:26, Nevin Brackett-Rozinsky via swift-evolution wrote: On Sun, May 28, 2017 at 7:04 PM, John McCall via swift-evolution mailto:swift-evolution@swift.org>> wrote: We need to add back tuple destructuring in closure parameter lists because this is a serious usability reg

Re: [swift-evolution] Revisiting SE-0110

le argument:"... (Int, Int) -> Int// function from Int and Int to Int ((Int, Int)) -> Int // function from tuple (Int, Int) to Int ..." Again, please note that SE-0110 is based on previous accepted proposals: SE-0066 and SE-0029. On May 29, 2017, at 1:32 PM, Vlad

Re: [swift-evolution] Revisiting SE-0110

On 29.05.2017 21:08, Nevin Brackett-Rozinsky wrote: Vladimir, using your function definitions I would like to have: // Two parameters: barParams{ t in } // invalid, too few parameters barParams{ (t) in } // invalid, too few parameters barParams{ x, y in }// valid, two parameters ba

Re: [swift-evolution] Revisiting SE-0110

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: Yes, I agree. We need to add back tuple destructuring in closure parameter lists because this is a serious usability regression. If we

Re: [swift-evolution] Revisiting SE-0110

ter { ((name, age)) in arg.age >= 18 } I.e. two pairs for parenthesis for tuple destructuring, and such syntax is similar to the type this closure should have : ((String, Int)) -> Bool On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution wrote: On 01.06.2017 0:42,

Re: [swift-evolution] Revisiting SE-0110

turing one parameter { (a, (b, c)) -> Int in } // error: add 'let' to destructure second parameter -- On Thu, Jun 1, 2017 at 3:32 PM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 01.06.2017 19:31, Tommaso Piazza wrote: Dear

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 wrote: Yes, I agree. We need to add back tuple dest

Re: [swift-evolution] Revisiting SE-0110

age)) in arg.age >= 18 } I.e. two pairs for parenthesis for tuple destructuring, and such syntax is similar to the type this closure should have : ((String, Int)) -> Bool > > > > On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution > mailto:swift-evolu

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 j

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 synt

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 wit

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 o

Re: [swift-evolution] Revisiting SE-0110

On 06.06.2017 15:32, Gwendal Roué wrote: Le 6 juin 2017 à 12:06, Vladimir.S mailto:sva...@gmail.com>> 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

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 mailto: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 wh

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 mailto:sva...@gmail.com>> 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)

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 SE-0110 and seeing a new proposal

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 mailto:swift-evolution@swift.org>> wrote: FWIW, after doing a project migration last night

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

On 07.06.2017 14:18, Gwendal Roué via swift-evolution wrote: Xiaodi, Adrian, you are actively pushing so that something that was allowed, well compiled (no runtime issue), and covered actual uses cases, becomes forbidden. Without any developer advantage that would somehow balance the change. T

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

On 07.06.2017 16:20, Gwendal Roué wrote: Le 7 juin 2017 à 15:11, Xiaodi Wu > a écrit : While SE-0025 was generally regarded as unfortunate, the thousands of emails that followed relitigating it were much, much worse. The removal of implicit tuple splatting, which

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

On 07.06.2017 21:33, Gwendal Roué wrote: Le 7 juin 2017 à 17:15, Vladimir.S mailto:sva...@gmail.com>> a écrit : On 07.06.2017 16:20, Gwendal Roué wrote: Le 7 juin 2017 à 15:11, Xiaodi Wu > a écrit : While SE-0025 was generally regarde

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 of

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 mailto:swift-evolution@swift.org>> wrote: Just a thought if parentheses is important, why the tuples are not? This is stated on the proposal (and

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, *

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 mailto:swift-evolution@swift.org>> a écrit : On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution mailto:swift-evolution@swift.org>> wrote: Well please no:

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 ASCI

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 mailto:swift-evolution@swift.org>> wrote: Well please no: 
|let fn2: ((Int, Int)) -> Void = { lhs, rhs in }| Instead use destructuring sugar pitched by Chris Lattn

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 mailto:swift-evolution@swift.org>> 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 <mailto:swift-

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 mailto:swift-evolution@swift.org>> a écrit : On Jun 7

Re: [swift-evolution] [Proposal] Change Void meaning

On 12.06.2017 11:48, Jérémie Girault via swift-evolution wrote: Hi here, As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples usage. After documenting myself about the changes which happened, I thought that they could be improved. Instead of fighting these propositions (

Re: [swift-evolution] Guard let

On 10.06.2017 7:07, Justin Oroz via swift-evolution wrote: First time trying to contribute, hopefully this is the proper channel to submit. I propose an addition to the guard let statement to allow for replacement of optionals with unwrapped values. ex) two current options obj.methodWithCal

Re: [swift-evolution] [Proposal] Change Void meaning

On 12.06.2017 21:04, Xiaodi Wu via swift-evolution wrote: On Mon, Jun 12, 2017 at 12:44 Jérémie Girault > wrote: Void was the empty tuple because arguments were tuples. As John explained, that is _not_ correct. Void was not motivated by anything to do wit

Re: [swift-evolution] [Proposal] Change Void meaning

John, could you clarify the details regarding function types, SE-0066 and SE-0110 implementations *planned* for Swift 4 release? I believe all these are important questions to be answered to understand the near feature of Swift and to be prepared for changes. Given : func fooParam(_ x: Int, _

Re: [swift-evolution] [Proposal] Change Void meaning

On 12.06.2017 23:17, Jens Persson via swift-evolution wrote: I think this proposal would be complicating rather than simplifying the type system, it would be adding a special rule. And it is not a step towards resolving the many parentheses-related inconsistencies that still remain. Here is an

Re: [swift-evolution] [Proposal] Change Void meaning

On 13.06.2017 9:42, David Sweeris via swift-evolution wrote: On Jun 12, 2017, at 10:45 PM, Gwendal Roué via swift-evolution wrote: "Discussing" with Xiaodi is a special experience, isn't it? He will bite and misrepresent you and your ideas until you get tired and your idea has been exhaust

Re: [swift-evolution] [Proposal] Change Void meaning

On 13.06.2017 3:35, John McCall wrote: On Jun 12, 2017, at 6:42 PM, Vladimir.S wrote: John, could you clarify the details regarding function types, SE-0066 and SE-0110 implementations *planned* for Swift 4 release? I believe all these are important questions to be answered to understand the

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On 14.06.2017 21:23, Haravikk via swift-evolution wrote: On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution > wrote: On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution mailto:swift-evolution@swift.org>> wrote: Sorry, initially sent off

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On 15.06.2017 0:51, David Hart wrote: On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution <mailto:swift-evolution@swift.org>> wrote: On 14.06.2017 21:23, Haravikk via swift-evolution wrote: On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution mailto:swift-evolution@

[swift-evolution] The state and the future of function types in Swift 4

I do understand that core team is very busy, but I hope they'll find a minute to reply in couple of words to this message. Even "we are still thinking about this" would be great. Of course any other's opinion is also very welcome. I think we all need some clarification about function types in S

Re: [swift-evolution] The state and the future of function types in Swift 4

On 16.06.2017 19:29, Douglas Gregor wrote: On Jun 14, 2017, at 3:29 PM, Vladimir.S via swift-evolution wrote: I do understand that core team is very busy, but I hope they'll find a minute to reply in couple of words to this message. Even "we are still thinking about this"

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

On 13.07.2017 9:24, Adrian Zubarev via swift-evolution wrote: One more thing I wanted to add. I would remove the restriction of An escape character at the end of the last line of a literal is an error, as no newlines follow. from this proposal and allow the trailing backslash in the l

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

On 13.07.2017 14:41, Adrian Zubarev wrote: Well even if my last pitch won’t happen it’s still would be possible to have trailing whitespaces in |"""| in it’s last line, the issue is that they aren’t visible. We do not want to bring that discussion back now, but we definitely will post Swift 4 re

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

On 02.08.2017 14:11, Víctor Pimentel Rodríguez via swift-evolution wrote: On Wed, Aug 2, 2017 at 12:26 PM, Tino Heth via swift-evolution mailto:swift-evolution@swift.org>> wrote: That would work as well, but it has the downside of forcing a potentially huge number of methods to be im

Re: [swift-evolution] Enums and Source Compatibility

Sorry if I misunderstood the subject, but shouldn't this also be a *consumer* decision, when one wants to keep own switch exhaustive or it is OK to process all possible future cases in 'default'? If enum is 'closed' - nothing is changed, as I understand, we have the same rules for switch as cu

[swift-evolution] private extension

Could someone remind please, was it decided to stick with 'private extension' means actually fileprivate access level for members declared in such extension or this could be discussed for Swift5? Currently, when private members are visible in type/extensions of that type in the same file, IMO

Re: [swift-evolution] private extension

FWIW, I can't agree that this particular subject leads to huge discussion/battle about all the access modifiers. It is just about 'private extension' inconsistency, not more. And it seems like there no(?) opinions that current situation with private extension has any sense. It really looks like

Re: [swift-evolution] Enums and Source Compatibility

On 10.08.2017 16:46, Matthew Johnson via swift-evolution wrote: On Aug 10, 2017, at 7:46 AM, James Froggatt via swift-evolution wrote: Since it seems to have been lost in the noise, I want to second with support for Xiaodi's syntax of having `default` appearing in the enum declaration itself.

Re: [swift-evolution] Enums and Source Compatibility

On 10.08.2017 3:58, Jordan Rose wrote: Hi, Vladimir. I think framing this as a consumer decision is the wrong place to start. There are some enums that definitely make sense to be "closed", all the time, with no additional annotations, including Foundation.NSComparisonResult and, well, Swift.Op

Re: [swift-evolution] Enums and Source Compatibility

On 10.08.2017 18:22, Adrian Zubarev via swift-evolution wrote: I think this design does not avoid you writing something like `private enum Foo { default ... }`, which is redudant as Jordan already pointed out in his previous post, nor does it have a consistent way of declaration: Why compiler

Re: [swift-evolution] Enums and Source Compatibility

On 11.08.2017 2:37, Jordan Rose wrote: Both you and Vladimir are bringing up this point, with Vladimir explicitly suggesting a "future" case that's different from "default". Again, the pushback we get here is that the "future" case is untestable…but maybe that's still an option worth having.

Re: [swift-evolution] Enums and Source Compatibility

On 12.08.2017 1:37, Jordan Rose wrote: On Aug 11, 2017, at 02:59, Vladimir.S mailto:sva...@gmail.com>> wrote: On 11.08.2017 2:37, Jordan Rose wrote: Both you and Vladimir are bringing up this point, with Vladimir explicitly suggesting a "future" case that's different from "default". Again,

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

On 29.08.2017 19:02, Wallacy via swift-evolution wrote: In this example i think we lose clarity, just looking for the code we cant know if this two line will run on parallel or not! Also, image.get blocks the thread, in this case we need the await anyway! And `async` can throws too... So the err

  1   2   3   4   5   6   7   >