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

I agree with the sentiment of the proposal, it does add value to overall efficiency of swift and make things simpler for the swift team, but as Matthew said a blanket ban will add noise to the code. Also this particular feature is one of those niceties about swift which makes it very welcoming to

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

If private is required to be tied to types forever and always, then yes, this proposal should be accepted. To do otherwise is to suggest that the use of "private" by beginners and the use of same-file extensions by beginners are incompatible. The former is silly; "private" is what beginners

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

> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution > wrote: > > > What is your evaluation of the proposal? > > If this is the last option we have to change the status quo, any renaming is > off the table, no further changes after Swift 4, and it's either

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

> On Apr 6, 2017, at 11:01 AM, Brad Hilton via swift-evolution > wrote: > > How about Person.name.get / Person.name.set for getter/setter references. We don't really want getter/setter references; we want one instance which represents the whole property and (if

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

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md First of all, to be clear: although my name is on this proposal, it's there because I worked on

[swift-evolution] [Review] SE-0166: Swift Archival & Serialization

Review of SE-0166 "Swift Archival & Serialization: "https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md This is an amazing proposal. I have one

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

> What is your evaluation of the proposal? If this is the last option we have to change the status quo, any renaming is off the table, no further changes after Swift 4, and it's either this or being stuck with 'fileprivate' until the end of time, then +1 from me. It will increase the convenience

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

> On Apr 7, 2017, at 04:18, Gwendal Roué via swift-evolution > wrote: > > - the private/fileprivate qualifier used not to be a intrinsic property of an > object (because one had to move from private to fileprivate as soon as an > extension was added). Now

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

Thanks Shawn. I understand that part. I asked mostly because Nate mentioned that we cannot have a default closure because it would force the use of try even when the default closure does not throw. I do t know if that is a current bug or feature to allow changing the default in the future to

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

> On Apr 7, 2017, at 2:15 PM, Félix Cloutier via swift-evolution > wrote: > > I don't necessarily think that the concept is a bad idea, but I think that > the interaction of Swift features facilitates poor coding decisions. For > example, the proposal interpolates

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

> What is your evaluation of the proposal? -1, approximately. > Is the problem being addressed significant enough to warrant a change to > Swift? I don't necessarily think that the concept is a bad idea, but I think that the interaction of Swift features facilitates poor coding decisions. For

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

> On Apr 6, 2017, at 1:35 PM, Joe Groff via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > >

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

> On 7 Apr 2017, at 9:10 am, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0169 "Improve Interaction Between private Declarations and > Extensions" begins now and runs through April 11, 2017. The proposal is >

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

> On Apr 7, 2017, at 12:01 PM, John McCall wrote: > >> On Apr 7, 2017, at 2:50 PM, Joe Groff wrote: >>> On Apr 7, 2017, at 11:48 AM, John McCall wrote: >>> On Apr 7, 2017, at 1:40 PM, Joe Groff wrote: > On

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

> On Apr 7, 2017, at 2:50 PM, Joe Groff wrote: >> On Apr 7, 2017, at 11:48 AM, John McCall wrote: >> >>> On Apr 7, 2017, at 1:40 PM, Joe Groff wrote: On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution

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

> On Apr 7, 2017, at 1:50 PM, Joe Groff via swift-evolution > wrote: > > >> On Apr 7, 2017, at 11:48 AM, John McCall wrote: >> >>> On Apr 7, 2017, at 1:40 PM, Joe Groff wrote: On Apr 7, 2017, at 10:20 AM, John McCall via

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

> On Apr 7, 2017, at 11:48 AM, John McCall wrote: > >> On Apr 7, 2017, at 1:40 PM, Joe Groff wrote: >>> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution >>> wrote: >>> On Apr 7, 2017, at 12:48 AM,

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

> On Apr 7, 2017, at 1:40 PM, Joe Groff wrote: >> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution >> wrote: >> >>> >>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor wrote: >>> >>> On Apr 6, 2017, at 9:46 PM,

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

• What is your evaluation of the proposal? -1, for two reasons: (from https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034897.html and follow-up) First, having the same beginning and ending delimiter, with no continuation character, makes it very easy for a syntax

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

> On Apr 6, 2017, at 8:59 PM, John McCall via swift-evolution > wrote: > >> On Apr 5, 2017, at 7:56 PM, Douglas Gregor wrote: >> >> Hello Swift community, >> >> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for >> Swift"

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

> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution > wrote: > >> >> On Apr 7, 2017, at 12:48 AM, Douglas Gregor wrote: >> >> >>> On Apr 6, 2017, at 9:46 PM, John McCall wrote: >>> On Apr 7, 2017, at 12:27

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

> On Apr 7, 2017, at 12:48 AM, Douglas Gregor wrote: > > >> On Apr 6, 2017, at 9:46 PM, John McCall wrote: >> >>> On Apr 7, 2017, at 12:27 AM, Rick Mann wrote: On Apr 6, 2017, at 20:37 , John McCall

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

> On Apr 7, 2017, at 8:37 AM, Jonathan Hull via swift-evolution > wrote: > I think that is why he is saying (and I agree), that ‘fileprivate’ needs to > be the soft-default. That way private will mean something. Keywords aren't completely arbitrary. Programmers

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

> On Apr 6, 2017, at 12:35 PM, 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: > >

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

I would like to see a much more coherent and simple access control system in Swift. And since the proposal to revert `private` to what it was before was rejected, it is better that` private` means really `private`. Then -1 for this proposal. (I think we could learn a lot from C # in this question

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

It probably depends on the positioning of the initializer. I strongly associate the collection initializer to the special case of UnsafeBufferPointer, and the result strings will probably be passed back to C at some point, where an embedded NUL terminates the string (inconsistently with what

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

> On Apr 7, 2017, at 8:32 AM, Jonathan Hull via swift-evolution > wrote: >> On Apr 7, 2017, at 3:51 AM, Goffredo Marocchi > > wrote: >> >> >> >> Sent from my iPhone >> >> On 7 Apr 2017, at 09:56, Jonathan Hull via

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

On Fri, Apr 7, 2017 at 5:47 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > Setting aside source compatibility concerns for a brief moment, is there > anyone who would choose this approach over reverting SE-0025, renaming the > current modifier, or maintaining the

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

> On Apr 7, 2017, at 10:32 AM, BJ Homer wrote: > > > On Apr 7, 2017, at 9:23 AM, Matthew Johnson > wrote: > >> The most common thing is to have some stored properties that are private and >> include a handful of

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

> On Apr 7, 2017, at 9:23 AM, Matthew Johnson wrote: > > The most common thing is to have some stored properties that are private and > include a handful of fileprivate (or higher) methods that operate on these > properties in the type declaration. All members that

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

> It does not remove the scoped access control, it only relaxes it in > extensions to types in the same file. Many of the use cases for scoped access given during the review of SE-0159 specifically related to restricting access between extensions in the same file. I don't personally use this,

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

> On Apr 7, 2017, at 9:48 AM, David Hart via swift-evolution > wrote: > >> >> On 7 Apr 2017, at 15:41, BJ Homer via swift-evolution >> > wrote: >> >> -0.5 >> >> SE-0159 was rejected because it was

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

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

Mostly as a matter of historical interest: The hard-coding of collection operators for KVC in Cocoa was more of a scope of documentation or API style decision than anything. The original implementation of KVC came from Enterprise Objects Framework (which then became WebObjects), and in both of

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

> On 7 Apr 2017, at 15:41, BJ Homer via swift-evolution > wrote: > > -0.5 > > SE-0159 was rejected because it was determined that some developers are > actively using strongly-scoped access control. This proposal removes that > strong scoping, so I do not see how

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

-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 making private more confusing and in away surprising. We have a clear

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

-0.5 SE-0159 was rejected because it was determined that some developers are actively using strongly-scoped access control. This proposal removes that strong scoping, so I do not see how we can reasonably reject that proposal but accept this one. The entire reason we're having this discussion

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

> On Apr 7, 2017, at 2:21 AM, 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:

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

I think that is why he is saying (and I agree), that ‘fileprivate’ needs to be the soft-default. That way private will mean something. His point that this gets rid of the primary use-case of ‘private’ (over ‘fileprivate’) is also extremely relevant. > On Apr 7, 2017, at 4:51 AM, Gwendal Roué

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

> On Apr 7, 2017, at 3:51 AM, Goffredo Marocchi wrote: > > > > Sent from my iPhone > > On 7 Apr 2017, at 09:56, Jonathan Hull via swift-evolution > > wrote: > >>> What is your evaluation of the proposal? >> >>

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

> Le 7 avr. 2017 à 13:44, Matthew Johnson via swift-evolution > a écrit : > > No. I believe it makes the language worse, not better. It doesn’t address > the real problems with access control. The largest problem is the inability > to form scopes between files

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

> > What is your evaluation of the proposal? -1. I have been a vocal proponent of scoped access all along. Despite that I really tried to keep an open mind about this proposal. In the end, I just don’t think it is the right decision. I can see why some people would like to consider a main

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

> What is your evaluation of the proposal? +1 Is is excellent: - the private/fileprivate qualifier used not to be a intrinsic property of an object (because one had to move from private to fileprivate as soon as an extension was added). Now private/fileprivate can be made meaningful, and

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

> What is your evaluation of the proposal? It is good, but incomplete, needs many clarifications, and could be well improved with visual examples. Some questions: - What's the destiny of \", \n, \t, etc? Saying that single quote don't need to be escaped is not enough. - The sentence "This

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:

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

Sent from my iPhone > On 7 Apr 2017, at 09:56, Jonathan Hull via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > Strong -1. Just rename ‘fileprivate’ to be less annoying. So, we keep being told it won't happen and our current Bly

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

Sent from my iPhone > On 7 Apr 2017, at 12:17, Haravikk wrote: > > >>> On 6 Apr 2017, at 21:47, David Hart wrote: >>> >>> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution wrote:

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

> On 6 Apr 2017, at 21:47, David Hart wrote: > >> >> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution >> > wrote: >> >> >>> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution >>>

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

> What is your evaluation of the proposal? Strong -1. Just rename ‘fileprivate’ to be less annoying. This proposal will make things even worse than they are currently. We will regret it just as much, if not more than, 0025. As others have mentioned, it is actively harmful: • It once again

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

> On Apr 7, 2017, at 10:35 AM, Andrey Fidrya wrote: > >> On 7 Apr 2017, at 07:57, Charlie Monroe via swift-evolution >> > wrote: >> >> -1 for reasons I've previously expressed in the discussions: >> >> - It

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

> On 7 Apr 2017, at 07:57, Charlie Monroe via swift-evolution > wrote: > > -1 for reasons I've previously expressed in the discussions: > > - It encourages everything to be stuffed in one file. > - It doesn't actually solve anything as the new private is very close

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

On Fri, Apr 7, 2017 at 1:10 AM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md >- What is your evaluation of the

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

> On Apr 7, 2017, at 12:56 AM, Jean-Daniel wrote: > >> Even though I think we were better off without scoped `private`, I *have* >> used it fruitfully on several occasions. These were typically in places >> where I wanted to restrict access to a small number of members

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

> Le 7 avr. 2017 à 03:53, Brent Royal-Gordon via swift-evolution > a écrit : > >> On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution >> > wrote: >> >>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu

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

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-of-Mon-20170313/033882.html Towards the end, the post

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

We should evaluate the proposal in terms of what it can do not in "we are upset we are not getting that old proposal reverted" or "I want something else which I know I am not going to get". Sorry if this is a bit direct, meant no offence. Sent from my iPhone > On 7 Apr 2017, at 01:05,

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

Sent from my iPhone > On 7 Apr 2017, at 00:25, Slava Pestov via swift-evolution > wrote: > > Strong -1. This is a source breaking change, but Swift 4 stage 2 is already > over. Considering the importance of access control for a lot of people and the rare chance

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

+1 this is perhaps the best compromise between the two views on access control I have seen in a while and the change is actually very tiny yet meaningful. Thanks David and Chris! Sent from my iPhone > On 7 Apr 2017, at 00:10, Douglas Gregor via swift-evolution >

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

> On Apr 6, 2017, at 21:46 , John McCall wrote: > >> On Apr 7, 2017, at 12:27 AM, Rick Mann wrote: >>> On Apr 6, 2017, at 20:37 , John McCall wrote: >>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution

[swift-evolution] Swift 4 — converging "phase 2" discussions

Hi everyone, In mid-February we kicked of "stage 2" for the discussion of evolution proposals for Swift 4: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032116.html The timetable set forth was to have discussions for "stage 2" go through April 1. The intent of

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

(If you'd like any further discussion to move over to the review thread, please let me know.) > On Apr 5, 2017, at 9:08 PM, Itai Ferber wrote: >>> In terms of an equivalent to encode(contentsOf:), keep in mind that this >>> would only work if the collection you're decoding

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

> On Apr 6, 2017, at 4:10 PM, Douglas Gregor via swift-evolution > wrote: > > What is your evaluation of the proposal? -1 I don't see how this "breaking" change is better than just reverting SE-025. SE-169 complicates private by making it even closer to