Re: [swift-evolution] Code blocks and trailing closures

> On Mar 15, 2017, at 3:35 AM, Rien via swift-evolution > wrote: > > What does the following code fragment do? > > serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return } > > The only possible answer is: I don’t know. No, that is incorrect.

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

I don’t think there’s much of a difference between adding an "optional" primitive (which has a default implementation in terms of a different primitive) and simply having that type adopt `Codable` itself and not be a primitive. You can still switch on the type dynamically (and we do), but you

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 4:01 PM, Kenny Leung via swift-evolution > wrote: > > Hi All. > > I’m not sure I’m understanding this proposal properly. In (old) Cocoa, two > places where key paths were used extensively was EOF/CoreData, and > WebObjects. I’m wondering how

Re: [swift-evolution] Swift's reflection

> On Mar 17, 2017, at 2:43 PM, Matthew Johnson via swift-evolution > wrote: > >> >> On Mar 17, 2017, at 3:42 PM, Joe Groff via swift-evolution >> > wrote: >> >> I hope that Mirror will ultimately be

Re: [swift-evolution] Code blocks and trailing closures

> On Mar 20, 2017, at 07:24 , Rien wrote: > > Another solution to the original problem would be to allow the parameter name > of the closure outside the functions parenthesis: > > func test(a: Int, onError: ()->Void) {…} > > could be called like this: > > test(5)

Re: [swift-evolution] Smart KeyPaths

Hi All. I’m not sure I’m understanding this proposal properly. In (old) Cocoa, two places where key paths were used extensively was EOF/CoreData, and WebObjects. I’m wondering how Smart KeyPaths will solve these two problems: 1. fetching data from a database and stuff it into objects that are

Re: [swift-evolution] Code blocks and trailing closures

I actually don't like this situation, either. I find it gets a bit confusing to know what's a block and what's just nested scope. I, too, have had an impulse to have a different keyword for returning from a block, but what I really want is for the entire scope of the block to be called out

[swift-evolution] Generalised concrete-type existentials

Now that SE-0156 has been accepted, I’ve been thinking recently that it might be nice to extend this proposal with some kind of generalised “concrete-type existential”. As I see it, there are two parts to an existential like the one proposed here: & For classes, the “concrete type” part of

Re: [swift-evolution] [Idea] Generic associated types

> On Mar 11, 2017, at 9:49 PM, Karl Wagner wrote: > > I have a model like this: > > protocol Promise { > associatedtype Result > } > > protocol Scanner { > associatedtype ScanPromise: Promise > > func promiseScan(from: Offset, until: (Offset, Item) -> T?) ->

Re: [swift-evolution] [Proposal] Factory Initializers

Huge +1 > On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution > wrote: > > Hi again everyone! > > Now that Swift 4 Stage 2 proposals are being considered, I thought it might > be time to revisit this proposal and see if it might align with the goals set

Re: [swift-evolution] Generalised concrete-type existentials

> That is to say that “Array & Equatable” would be a nonsense constraint, > because Array does not conform to Equatable and will never conform to > Equatable. Actually, now that I write it out, even that isn’t true. Somebody might retroactively add conformances after importing your library.

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

I also disagree with the proposal, and Drew's explanation is spot on. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Factory Initializers

+ IntMax.max On Tue, Mar 21, 2017 at 12:07 PM, Greg Parker via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi again everyone! > > Now that Swift 4 Stage 2 proposals are being

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

I am still on the -1 side of this. I leverage the swift 3 enhanced encapsulation aspects of private fairly heavily and would rather see any additional efforts take place on needs of exposing things for subclasses to work with while hiding them from clients of those classes (better then protected

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

+1 One less level to explain and not much lost in the shuffle. On Mon, Mar 20, 2017 at 8:44 PM, Lucas Neiva via swift-evolution < swift-evolution@swift.org> wrote: > I think it's worth simplifying the access levels by removing > `fileprivate`. Changing `private` to cover the common file-level

Re: [swift-evolution] Smart KeyPaths

That is very interesting: "formatting templates that are well typed." Would that be like a template and keypaths that were archived to a file, similar to a .nib file? > On Mar 20, 2017, at 7:28 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 20, 2017, at

Re: [swift-evolution] [Proposal] Factory Initializers

> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution > wrote: > > Hi again everyone! > > Now that Swift 4 Stage 2 proposals are being considered, I thought it might > be time to revisit this proposal and see if it might align with the goals set > forth

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

> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution > wrote: > > Charles Srstka's added comment, while intriguing, poses a problem in > argumentation. One of the points being made above about the major advantage > of new `private` over `fileprivate` is

Re: [swift-evolution] Fwd: Re: Smart KeyPaths

If a character had to be used to denote key paths then I would prefer this one: 1. Type:path.to.value and instance:path.to.value I feel like the # screams at me. :-) > On Mar 20, 2017, at 1:52 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Mar 20,

[swift-evolution] Proposed amendment to SE-0138: Normalize UnsafeRawBufferPointer Slices

This proposal amends SE-0138: Normalize UnsafeRawBufferPointer Slices to fix a design bug: https://github.com/apple/swift-evolution/pull/651 The issue was discussed on swift-evolution in Nov/Dec: See [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

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

> On Mar 20, 2017, at 4:54 PM, Douglas Gregor wrote: > > Hello Swift community, > > The review of SE-0159 "Fix Private Access Levels" begins now and runs through > March 27, 2017. The proposal is available here: > >

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

> On Mar 20, 2017, at 4:54 PM, Douglas Gregor wrote: > https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md > > > What is your

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

I think it's worth simplifying the access levels by removing `fileprivate`. Changing `private` to cover the common file-level cases brings no disadvantages IMO, since there's always the option of moving a declaration to a separate file. (I seem to disagree with a lot of opinions on here, that

Re: [swift-evolution] Smart KeyPaths

Ah, yes, that would be annoying if editing .xib files caused SourceKitService dialogs to pop up every five seconds, the way editing .swift files does. Charles > On Mar 20, 2017, at 9:39 PM, Kenny Leung via swift-evolution > wrote: > > Wouldn’t this require the

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

> On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0159 "Fix Private Access Levels" begins now and runs through > March 27, 2017. The proposal is available here: > >

Re: [swift-evolution] Smart KeyPaths

Wouldn’t this require the Swift compiler and the original binary to work properly? -Kenny > On Mar 20, 2017, at 6:52 PM, Ricardo Parada wrote: > > That is very interesting: "formatting templates that are well typed." > > Would that be like a template and keypaths that were

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

Hello Swift community, 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 Reviews are an important part of the Swift

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

+1 for me too. The distinction always felt too nitpicky to me. File level access as the most limited form of access for the private keyword seems to me to be the simplest and easiest concept to understand. The example provided of code that would break after this change feels like an anti

Re: [swift-evolution] [Idea] Generic associated types

Totally +1 here. On Mon, Mar 20, 2017 at 11:12 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 11, 2017, at 9:49 PM, Karl Wagner wrote: > > I have a model like this: > > protocol Promise { > associatedtype Result > } > > protocol

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

> > What is your evaluation of the proposal? +1 > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. Making scope private be the soft default (private) created much confusion . The incredible overlap that this change created for fileprivate and private is

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

> > • What is your evaluation of the proposal? > I think it could stand to make a bit of a stronger case, but I am strongly in favor of the outcome. The introduction of fileprivate was disappointing to me when it happened, and I've yet to encounter a situation where it has been beneficial, but

Re: [swift-evolution] [Proposal] Factory Initializers

I'm in favor of this pattern. > On Mar 20, 2017, at 4:40 PM, Jonathan Hull via swift-evolution > wrote: > > Huge +1 > > >> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution >> wrote: >> >> Hi again everyone! >> >> Now

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 19, 2017, at 11:02 PM, jaden.gel...@gmail.com wrote: > > You mean overloaded, not shadowed, right? No. What I mean by shadowed is this: struct Foo { // you write this: let bar: Int // compiler automatically synthesizes a static keypath: static let

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad On Mar 20, 2017, at 6:18 AM, Rien via swift-evolution wrote: >> >> On 20 Mar 2017, at 12:12, David Hart via swift-evolution >> wrote: >> >> >> >>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] Code blocks and trailing closures

Xcode can already draw boxes for nesting scopes, but it’s disabled by default. You’ll find it under: Editor > Code Folding > Focus Follows Selection. That said, IIRC it’s been mentioned on this list that (I’m paraphrasing) we should try and avoid designs that rely on editor functionality, and

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Sent from my iPad > On Mar 20, 2017, at 1:43 AM, David Hart wrote: > > >> On 20 Mar 2017, at 02:09, Matthew Johnson via swift-evolution >> wrote: >> >> On Mar 19, 2017, at 2:21 PM, Tony Parker wrote:

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On 17 Mar 2017, at 17:07, Tony Parker wrote: > > Hi Karl, > >> On Mar 17, 2017, at 12:20 AM, Karl Wagner via swift-evolution >> > wrote: >> >> >>> On 16 Mar 2017, at 21:48, Slava Pestov via

Re: [swift-evolution] Smart KeyPaths

+1. This is my favorite solution so far. With ‘Person.keypath.name' it is obvious that we are creating a key path. There is no ambiguity for the reader. With autocomplete it will be very little extra typing anyway… Thanks, Jon > On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On 20 Mar 2017, at 02:09, Matthew Johnson via swift-evolution > wrote: > > >>> On Mar 19, 2017, at 2:21 PM, Tony Parker wrote: >>> >>> >>> On Mar 19, 2017, at 12:14 PM, Matthew Johnson >>> wrote: >>> >>> >>>

Re: [swift-evolution] Smart KeyPaths

> > On 20 Mar 2017, at 12:12, David Hart via swift-evolution > wrote: > > > >> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >> wrote: >> >> +1. This is my favorite solution so far. >> >> With ‘Person.keypath.name' it

Re: [swift-evolution] Smart KeyPaths

> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution > wrote: > > +1. This is my favorite solution so far. > > With ‘Person.keypath.name' it is obvious that we are creating a key path. > There is no ambiguity for the reader. With autocomplete it will

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 19, 2017, at 8:19 PM, Matthew Johnson wrote: > > First, your solution does not allow a user to see a context if they can't > name the type (you can't get it as Any and use reflection, etc). What I meant is that, if you retrieve the context, you know it is of

[swift-evolution] [Accepted] SE-0156: Class and Subtype existentials

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md Hello Swift community, The review of SE-0156 “Class and Subtype Existentials” ran from February 28...March 7, 2017. The proposal was very well-received and is accepted with one

Re: [swift-evolution] Code blocks and trailing closures

Another solution to the original problem would be to allow the parameter name of the closure outside the functions parenthesis: func test(a: Int, onError: ()->Void) {…} could be called like this: test(5) onError: { myErrorHandler() } Myself, I would like this. It makes clear what the closure

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >> wrote: >> >> +1. This is my favorite solution so far. >> >> With ‘Person.keypath.name'

Re: [swift-evolution] Code blocks and trailing closures

> On 20 Mar 2017, at 14:24, Rien via swift-evolution > wrote: > > Another solution to the original problem would be to allow the parameter name > of the closure outside the functions parenthesis: > > func test(a: Int, onError: ()->Void) {…} > > could be called

Re: [swift-evolution] Smart KeyPaths

I like it the way they have it in the proposal because it is consistent with referencing methods and initializers. And as mentioned previously it can be disambiguated on the edge cases. > On Mar 20, 2017, at 9:11 AM, Matthew Johnson via swift-evolution > wrote:

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution > wrote: > > > >> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution >> wrote: >> >> >> >>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution > wrote: > >> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution >> > wrote: >> >> >> >>> On 20 Mar 2017, at 10:39,

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 20, 2017, at 5:34 AM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 8:19 PM, Matthew Johnson > > wrote: >> >> First, your solution does not allow a user to see a context if they can't >> name the

Re: [swift-evolution] Code blocks and trailing closures

> On 20 Mar 2017, at 15:42, Haravikk wrote: > > >> On 20 Mar 2017, at 14:24, Rien via swift-evolution >> wrote: >> >> Another solution to the original problem would be to allow the parameter >> name of the closure outside the

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

Sorry, didn’t see the other threads about this. Sooner is better but I’m glad to know it’s at least planned. Jon > On Mar 20, 2017, at 12:39 PM, Jon Shier wrote: > > So when is this transition happening? The sooner the better, as Mail > can’t really handle threads

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

So when is this transition happening? The sooner the better, as Mail can’t really handle threads with large messages, like the recent evolution threads about Foundation serialization and decoding. It just stops rendering messages. Discourse would help a lot for these sorts of

Re: [swift-evolution] Property Selectors

> On Mar 19, 2017, at 6:25 PM, Andrew Thompson wrote: > > Opps, should have sent this to the mailing list…. > > That sounds pretty good.  I find the response from the community to this > proposal to be pretty cool. > > While reading some of the discussion around your

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi Kenny, > On Mar 19, 2017, at 9:53 PM, Kenny Leung via swift-evolution > wrote: > > Hi All. > > Forgive me if I missed it - I haven’t read the proposal in full detail - but > it seems to make no mention of archiving graphs with circular references. Is > this

[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 > wrote: On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution

Re: [swift-evolution] Fwd: Re: Smart KeyPaths

> On Mar 20, 2017, at 12:37 PM, Vladimir.S via swift-evolution > wrote: > > 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 >>>