Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution > wrote: > > I think I we can live with the original three: public, internal, and private > > Where public is visible to all, > Internal is visible to all within the module, and private is visible only to >

Re: [swift-evolution] [swift-users] for in? optionalCollection {

This could come for almost free after SE-0143 is implemented: an Optional of a Sequence could itself be made to conform to Sequence. It would cost no new syntax. extension Optional: Sequence where Wrapped: Sequence { func makeIterator() -> AnyIterator { switch self { case .some(let

Re: [swift-evolution] final + lazy + fileprivate modifiers

FWIW, you're not the first to propose these names. `public(open)` was suggested during the `open` debate and rejected in favor of `open`. `private(file)` was suggested during the `fileprivate` debate and rejected in favor of `fileprivate`. `protected` and `abstract` have been suggested on this

Re: [swift-evolution] final + lazy + fileprivate modifiers

Some corrections and additions to my previous email: public(open) // if open is absent, the method is “closed” protected // (yes, we and Cocoa still use classes) internal private(file) // if file is absent, the method is really, really private ​ And one observation: protected and abstract as

Re: [swift-evolution] final + lazy + fileprivate modifiers

Well. I really would like to see something like this in Swift: public(open|closed) protected // (yes, we and Cocoa still use classes) internal private(file) I would like the abstract modifier to any access level because, well... We and Cocoa still use classes. ;) It could be something like

Re: [swift-evolution] [Pitch] consistent public access modifiers

Also, note that there will be at least one other similar annotation, but for structs — the evolution document calls it @fixedContents. We want a way to declare that the set of stored properties in a struct will never change, allowing clients to make assumptions about its layout. Unlike @closed

Re: [swift-evolution] final + lazy + fileprivate modifiers

I've found the new private to be useful in various scenarious, where I nest classes/structs/enums inside each other. Without it, it's impossible to declare a member with the intend to be used privately by just that class. With the old private, it was not obvious whether a private member is

Re: [swift-evolution] final + lazy + fileprivate modifiers

I think I we can live with the original three: public, internal, and private Where public is visible to all, Internal is visible to all within the module, and private is visible only to the class and the same file. We can still fulfill the same roles that the current five fill. Open can become

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer wrote: > I know that private was scoped to files before Swift 3. > > Fileprivate should obviously be removed because it is, like I said > previously, just a poor man’s package access level. Yes, private was scoped > to a file

Re: [swift-evolution] final + lazy + fileprivate modifiers

I know that private was scoped to files before Swift 3. Fileprivate should obviously be removed because it is, like I said previously, just a poor man’s package access level. Yes, private was scoped to a file before Swift 3, but at least there wasn’t two kinds of private for a single file.

Re: [swift-evolution] final + lazy + fileprivate modifiers

What was added in Swift 3 was `private`; the old `private` was renamed `fileprivate` with no change in behavior. Certainly, submodules are a big topic that deserves careful consideration. But the question being discussed here is about rolling back the change that was implemented in Swift 3 by

Re: [swift-evolution] final + lazy + fileprivate modifiers

Fileprivate is a feature that should not have been added to Swift 3 because it is in the end just a needlessly limited version of the Java package access level. Fileprivate forces me to put all types which are related on an implementation level into the same file while Java packages allow me to

Re: [swift-evolution] Strings in Swift 4

Hi Ted, Dave is on vacation next two weeks so this is a reply on behalf of both him and me: > On Feb 12, 2017, at 10:17, "Ted F.A. van Gaalen" > wrote: >> On 11 Feb 2017, at 18:33, Dave Abrahams >

Re: [swift-evolution] final + lazy + fileprivate modifiers

I vehemently agree on these points. New-private and fileprivate "[add] more information" to a file the same way requiring `self.` and other sorts of visual noise that Swift normally eschews. I wish for the Swift community to be introspective enough to count both its successes and failures.

Re: [swift-evolution] final + lazy + fileprivate modifiers

I find the final keyword useful when I want to communicate that this class should not be subclassed. I think the behavior should remain the same since it is useful. On Sun, Feb 12, 2017 at 5:15 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > On Feb 12, 2017, at 3:52

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 3:52 PM, Xiaodi Wu wrote: > > On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson > wrote: > >> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson wrote: > > On Feb 12, 2017, at 3:45 PM, Xiaodi Wu wrote: > > On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson > wrote: > >> >> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via

Re: [swift-evolution] final + lazy + fileprivate modifiers

I agree with Xiaodi on this. Given the common Swift design pattern of “small core type, with additional functionality in thematic extensions” it seems to me that a truly beneficial model would allow users to separate large extensions into their own files, while still maintaining encapsulation.

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu wrote: > > On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson > wrote: > >> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson wrote: > > On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't > actually meaningful. Here's why: >

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution > wrote: > > _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't > actually meaningful. Here's why: > > If I see `fileprivate` and can understand that to mean "gee, the author >

Re: [swift-evolution] final + lazy + fileprivate modifiers

I should add, on the topic of looking at real-world evidence: the question we really want to answer is, "Are authors taking advantage of (or finding useful) the new distinction between private and fileprivate?" To me, that people are leaving the migrator's `fileprivate` in place suggests that in

Re: [swift-evolution] final + lazy + fileprivate modifiers

_Potentially_ meaningful, certainly. But what I'm hearing is that it isn't actually meaningful. Here's why: If I see `fileprivate` and can understand that to mean "gee, the author _designed_ this member to be visible elsewhere inside the file," then it's actually meaningful. OTOH, if I see

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

Hi Matthew, Your arguments made sense to me. I modified the proposal to choose strategy number 3: deprecating and removing class over several versions to favour AnyObject. Mind having another proof read?

Re: [swift-evolution] final + lazy + fileprivate modifiers

I get your point, but as long as we are talking about functions that are all in a single file, I hardly see how the distinction can be "potentially important". > Le 12 févr. 2017 à 21:14, Chris Lattner a écrit : > > I don't fully agree: you are right that that is the case

Re: [swift-evolution] final + lazy + fileprivate modifiers

Le 12 févr. 2017 à 12:24, Chris Lattner via swift-evolution a écrit : > > On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > wrote: >> Fileprivate >> >> I started the discussion early during the Swift 4 timeframe that I regret

Re: [swift-evolution] final + lazy + fileprivate modifiers

I don't fully agree: you are right that that is the case when writing code. However, when reading/maintaining code, the distinction is meaningful and potentially important. -Chris > On Feb 12, 2017, at 12:02 PM, Xiaodi Wu wrote: > > If the overwhelming use case is that

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 12 Feb 2017, at 21:02, Xiaodi Wu via swift-evolution > wrote: > > If the overwhelming use case is that developers should pick one over the > other primarily because it looks nicer, then blindly click the fix-it when > things stop working, then the distinction

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 12 Feb 2017, at 18:24, Chris Lattner wrote: > > On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > > wrote: >> Final >> Can someone tell me what is the use of 'final' now that we have 'public' >>

Re: [swift-evolution] final + lazy + fileprivate modifiers

If the overwhelming use case is that developers should pick one over the other primarily because it looks nicer, then blindly click the fix-it when things stop working, then the distinction between private and fileprivate is pretty clearly a mere nuisance that doesn't carry its own weight. On Sun,

Re: [swift-evolution] final + lazy + fileprivate modifiers

> Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution > a écrit : > > On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > > wrote: >> Final >> Can someone tell me what is the use of

Re: [swift-evolution] Fileprivate vs private

> On Feb 12, 2017, at 9:19 AM, Milos Jakovljevic via swift-evolution > wrote: > > Hi everyone, > > Can anyone elaborate whats the idea behind private and fileprivate ? Or > better yet what is the purpose of fileprivate ? See SE-0025 and the discussion links at

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution wrote: > Final > Can someone tell me what is the use of 'final' now that we have 'public' > default to disallowing subclassing in importing modules? I know that 'final' > has the added constraint of

[swift-evolution] Fileprivate vs private

Hi everyone, Can anyone elaborate whats the idea behind private and fileprivate ? Or better yet what is the purpose of fileprivate ? Thanks, Milos Sent from my iPad ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 12, 2017, at 10:39 AM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Alternative: leave “public enum” as it is now, and spell the resilient > version “@resilient enum” The problem with this approach is that the “default” is the stricter contract

Re: [swift-evolution] [Pitch] consistent public access modifiers

Alternative: leave “public enum” as it is now, and spell the resilient version “@resilient enum” Nevin On Sunday, February 12, 2017, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 12, 2017, at 10:24 AM, David Hart

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 10:34 AM, Charlie Monroe via swift-evolution > wrote: > > >> On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution >> > wrote: >> >> I was reading this nice listing of Swift

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution > wrote: > > I was reading this nice listing of Swift keywords > (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh > >

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 12, 2017, at 10:24 AM, David Hart wrote: > > > On 12 Feb 2017, at 16:38, Matthew Johnson > wrote: > >> >>> On Feb 12, 2017, at 12:50 AM, David Hart >> > wrote:

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 10:19 AM, David Hart via swift-evolution > wrote: > > I was reading this nice listing of Swift keywords > (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh > >

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 12 Feb 2017, at 16:38, Matthew Johnson wrote: > > >> On Feb 12, 2017, at 12:50 AM, David Hart wrote: >> >> Hi Matthew, >> >> I've read your proposal ideas and most of the discussions on the thread, and >> I'd like to provide some personal

[swift-evolution] final + lazy + fileprivate modifiers

I was reading this nice listing of Swift keywords (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh) and three of them struck me as potentially not long for this world and I was thinking if we needed/could deprecate them before any kind of ABI

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 12, 2017, at 12:50 AM, David Hart wrote: > > Hi Matthew, > > I've read your proposal ideas and most of the discussions on the thread, and > I'd like to provide some personal feedback. > > Swift already has a complicated "access modifier" story so I think we really

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 4:41 PM, Karl Wagner wrote: > > >> On 11 Feb 2017, at 20:50, Matthew Johnson via swift-evolution >> > wrote: >> >>> >>> On Feb 11, 2017, at 12:40 PM, Xiaodi Wu >>

Re: [swift-evolution] for in? optionalCollection {

> I have a question for you. How do you think we could use this pattern in the > generalised situation: In general ;-) I like things that can be used universally much more than a huge number of special cases. But here, I'm not sure if it's not an increase of complexity: I often if statements

Re: [swift-evolution] for in? optionalCollection {

Most alternatives already where discussed in swift-user: > Imho the "forEach" solution is flawed, because you can't break the loop, and > the "?? []" isn't perfect either: > I hope the compiler can optimise so that the assembly is as fast as the "if > let" solution, but even if this is the

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 2:41 PM, Karl Wagner via swift-evolution > wrote: > For example, the compiler squashes the layout of an enum in to the smallest > type which can represent all of its cases - so if you only have 2 cases, your > enum will be an Int1 (possibly

Re: [swift-evolution] [Pitch] consistent public access modifiers

Hi Brent, I understand that SubC.cc as C does not work, that’s the case in my bikeshedding example I noticed that because the enum case is always known at compile time, there will be an error with informs you to downgrade SubC to one of its super-types case. Plus I forget about the

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 2:25 AM, Adrian Zubarev via swift-evolution > wrote: > > // Allowed because `C` is open, and open allows sub-typing, conforming > // and overriding to the client > enum SubC : C { > case cc > } There's a subtle mistake here. For a sum