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

Hey Slava, > On 22 Feb 2017, at 23:07, Slava Pestov via swift-evolution > wrote: > > >> On Feb 21, 2017, at 4:19 PM, David Waite via swift-evolution >> wrote: >> >> >>> On Feb 21, 2017, at 2:27 AM, Joanna Carter

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

> On Feb 21, 2017, at 4:19 PM, David Waite via swift-evolution > wrote: > > >> On Feb 21, 2017, at 2:27 AM, Joanna Carter >> wrote: >> >> But in the Swift world, we now have the ability to extend almost any type, >> except Any and

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

> Le 22 févr. 2017 à 01:19, David Waite a écrit : > >> Is there not a value in forking this discussion into which keywords are >> truly about visibility control and which are about extensibility control? > > Possibly; they are two axes. However, I’m hoping that

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

> On Feb 21, 2017, at 2:27 AM, Joanna Carter > wrote: > > But in the Swift world, we now have the ability to extend almost any type, > except Any and AnyObject, which appear to be protected by some deep and dark > mechanism within the compiler. So, just as

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

Sorry to beat this like a drum : How is swift 3 extensibility harmful exactly? Do you have specific examples when extensibility was harmful in a project? This probably deserves its own thread if the examples are substantial. > On Feb 21, 2017, at 1:27 AM, Joanna Carter via

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

> On Feb 20, 2017, at 10:04 AM, Joanna Carter via swift-evolution > wrote: > > Otherwise known in my language as : > > public - anywhere > internal - anywhere inside the module > private - only inside current type > extensible - in current file and in

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

Joanna Carter Carter Consulting Envoyé de mon iPad > Le 20 févr. 2017 à 18:40, Vladimir.S a écrit : > >> On 20.02.2017 20:04, Joanna Carter wrote: >> I'm not sure why ; with 'extensible' available to code within the same >> file, why would you still need fileprivate anywy?

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

On 20.02.2017 20:04, Joanna Carter wrote: Le 20 févr. 2017 à 17:25, Vladimir.S a écrit : Well, in general I support your opinion, but there is one question not answered by your 'extensible' modifier. It is common to have access to type's internals in the same file from

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

> On 20 Feb 2017, at 16:43, Matthew Johnson wrote: > > >> On Feb 20, 2017, at 12:31 AM, David Hart via swift-evolution >> wrote: >> >> >> >>> On 20 Feb 2017, at 00:52, Tony Arnold via swift-evolution >>>

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

On 20.02.2017 18:25, Joanna Carter via swift-evolution wrote: Le 20 févr. 2017 à 15:30, Dimitri Racordon a écrit : I think that fileprivate is fine, and that the drawback of having very large files is acceptable, Having had to debug code for my clients in past

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

> On Feb 20, 2017, at 5:43 AM, Ross O'Brien via swift-evolution > wrote: > > My two cents: > > I like that Swift has a way of restricting access to some properties and > functions to just the scope in which they're declared (Swift 3 private). > > At the moment I

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

> Having had to debug code for my clients in past years, I can say that, from > real world experience, large code files are a $&§*% nightmare. This is what I meant when I said that everybody has a story about that time it was so hard to do this because of that. This is not to say that I don’t

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

> On Feb 20, 2017, at 12:31 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Feb 2017, at 00:52, Tony Arnold via swift-evolution >> wrote: >> >> >>> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution >>>

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

> Le 20 févr. 2017 à 15:30, Dimitri Racordon a > écrit : > > I think that fileprivate is fine, and that the drawback of having very large > files is acceptable, Having had to debug code for my clients in past years, I can say that, from real world experience,

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

On Mon, Feb 20, 2017, at 02:29 AM, Goffredo Marocchi via swift-evolution wrote: > Maybe the burden of proof required for this change is not met even though > it frustrates those who dislike fileprivate. It's more frustrating that it's seemingly now imperative to get the burden of proof to remove

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

> On Feb 20, 2017, at 3:43 AM, Ross O'Brien via swift-evolution > wrote: > > As Goffredo Marocchi said, I don't want to return to Objective C's dozen > import statements at the top of a file, but how would we denote that a file > is a member of a submodule? At the

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

> Le 20 févr. 2017 à 13:29, David Hart a écrit : > > I don't agree with this point. I'm for a file-based private, but I definitely > do NOT want access control eliminated, quite the contrary. I think the > arguments are much subtle than what is presented here. I want strong

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

I don't agree with this point. I'm for a file-based private, but I definitely do NOT want access control eliminated, quite the contrary. I think the arguments are much subtle than what is presented here. I want strong access control, and to have that, the access control modifiers should be

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

> Let's be clear here: Are you thinking of this exclusively as a feature for > override points, or are you asking for a `protected` feature in general? What I am trying to get across is that the concept of fileprivate, as it stands, is almost a waste of effort, in that it only allows privileged

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

My two cents: I like that Swift has a way of restricting access to some properties and functions to just the scope in which they're declared (Swift 3 private). At the moment I tend to use the Swift idiom of declaring a type, and then declaring an extension each protocol conformance, and

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

> It's not that it's not meant to be called, but to be called from certain > context. Coming back to a codebase after a while, you don't need to remember > that method is not meant to be called out of certain context and if you name > your methods well, you don't really need to go and take a

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

I really don’t like the idea of an attritional access control file. Not everybody is using an IDE that automagically creates the structures and files for your favourite language, and I would hate to see Swift go the Java way where it’s impossible to build something seriously without Eclipse or

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

Ok, on this I can agree... and I will. It try to mention how judging things by how "Swifty" they are makes us seem like a cult... but then again we are programmers/engineers... that word may very well apply appropriately :). Sent from my iPhone > On 20 Feb 2017, at 08:46, Jonathan Hull

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

> On 20 Feb 2017, at 09:39, Goffredo Marocchi via swift-evolution > wrote: > > Please, almost anything but going back to the horrible Objective-C pattern of > private headers (that end up included on in the implementation files) :/. Why not a best of both

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

I didn’t say we should have headers, I said we need something that maps to those use cases in a swift-y way. Just being able to mark something as internal to the type, and a way to opt-in to seeing those things within a particular file. Thanks, Jon > On Feb 20, 2017, at 12:39 AM, Goffredo

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

Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/. Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth

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

> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution > wrote: > > A third point (which is a bit more complex/convoluted) is that fileprivate > remained an essential language feature because it allows implementation in > extensions, and allows a simple

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

Maybe the burden of proof required for this change is not met even though it frustrates those who dislike fileprivate. I honestly think our energies are better spent on other parts of the language than arguing on this... unless the discussion has time to grow into a proper holistic manifesto on

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

> On Feb 19, 2017, at 7:29 PM, David Waite wrote: > > Swift 2’s access modifiers had a very simple ‘elevator pitch’ - > “If you are writing code, by default everything within the module (app or > library) your are working in can see it, but other modules cannot.

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

Swift 2’s access modifiers had a very simple ‘elevator pitch’ - “If you are writing code, by default everything within the module (app or library) your are working in can see it, but other modules cannot. If you want other modules to see features of your module, you make them public. If

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

Sent from my iPad > On Feb 19, 2017, at 5:52 PM, Tony Arnold via swift-evolution > wrote: > > >> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution >> wrote: >> >> We need more examples to make this case. > > How do we

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

> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution > wrote: > > We need more examples to make this case. How do we provide those examples? This thread has been actively discussed for close to a week now, so it would be good to do something concrete

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

> On Feb 19, 2017, at 7:16 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution >> wrote: >> >> >> >>> On 19 Feb 2017, at 10:20, Goffredo

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

I think this is the not an easy topic to get right, there is not enough evidence in practice to remove it in terms of it being actively harmful and having a better solution at hand. What you see as being not awesome for protocols and extensions others may see taking it away as a sacrifice that

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

> On 19 Feb 2017, at 18:10, Goffredo Marocchi wrote: > > Good thing that both can exist then :). One day we may even get things such > as abstract classes and be allowed to model abstentions wth classes and > reference types better without it being seen as an attack to

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

Good thing that both can exist then :). One day we may even get things such as abstract classes and be allowed to model abstentions wth classes and reference types better without it being seen as an attack to value types ;).. Sent from my iPhone > On 19 Feb 2017, at 13:55, David Hart

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

Sent from my iPad > On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution > wrote: > > > >> On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution >> wrote: >> >> The current private is closer to other languages than

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

> On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution > wrote: > > The current private is closer to other languages than the previous one we had > which now has in fileprivate a better name. It is closer, but it's not a goal for Swift to always follow

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

Coming from any other modern language has a much harsher friend in default methods in protocol extensions and having code execution once again depend on the reference type in those cases and no protection to tell you that your code is at risk of this occurring (your class method only called if

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

A parabel: Nobody is going to invest a week of his time so save $1 of taxes per year. Yet somebody who receives those millions of dollars will invest -if need be- all of his time to keep it coming. Guess who wins? Same with private. There is no BIG harm. But a great many of very little minor

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

How exactly is the use of scope private harmful? Do you have specific examples when scope private was harmful? > On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution > wrote: > > On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution

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

On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution wrote: > I don’t think there is evidence that scope private in Swift3 is > "actively harmful”. This thread would quite simply not exist if not to present exactly that evidence. It exists; we, the change's detractors,

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

> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution > wrote: > > While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary

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

> On Feb 17, 2017, at 10:56 PM, Xiaodi Wu wrote: > > On Fri, Feb 17, 2017 at 3:46 PM, Charlie Monroe > wrote: > >> On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution >>

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

I searched thought my code and most uses of fileprivate were for same-file extensions which would be solved by #2 as well. The other usages are mostly "related" types, which could possibly work with #2 if these were made inner types instead. Two examples: A "Slots" struct with a collection of

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

> On Feb 17, 2017, at 2:15 PM, Joanna Carter via swift-evolution > wrote: > > There are also times when I want to declare a base class that I am expecting > users to derive from, especially an abstract class. I want a means of > declaring that certain stuff can only

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

> While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary complications that > only serve to clutter the language. > > It would make a lot more sense to just have

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

My 2c: +1 to reverting private to the Swift 2 meaning and deprecating or using fileprivate as an alias for private. As a framework developer I am constantly deciding backward and forwards to go private only to realise that my embracing extensions makes it impossible to allow internal

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

My ideal scenario: 1) Go back to Swift 2 meaning of private 2) Add the ‘hidden’ axis I talked about in another thread. This will provide the capabilities of protected + friend (and allow extensions organized across files) using a consistent file-based approach that is easy to reason about.

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

> On Feb 17, 2017, at 6:10 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez > wrote: > >> >> From Ted. >>> Relative to Swift 3, the bar for such changes is

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

Sent from my iPad > On Feb 17, 2017, at 4:51 PM, Xiaodi Wu wrote: > > Although there was willingness to depart from conventions in other C-style > languages, I believe it was decided that having a counterpart to other > languages' "private" that isn't named private

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

Sent from my iPad > On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez wrote: > > From Ted. >> Relative to Swift 3, the bar for such changes is significantly higher: >> >> The existing syntax/API being changed must be actively harmful. >> The new syntax/API must clearly be

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

Sent from my iPad > On Feb 17, 2017, at 6:44 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution >> wrote: >>> On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution

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

From Ted. > Relative to Swift 3, the bar for such changes is significantly higher: > > The existing syntax/API being changed must be actively harmful. > The new syntax/API must clearly be better and not conflict with existing > Swift syntax. > There must be a reasonably automatable migration

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

On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> Here, a function call is an _intentional_ act. Writing a function not >> meant to be

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

On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Here, a function call is an _intentional_ act. Writing a function not > meant to be called is an _intentional_ act. It is strange that you would > demand the compiler to stand between two of your

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

> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution >> wrote: >> >> Personally I feel enforced encapsulation of implementation detail to the

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

> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution > wrote: > > Personally I feel enforced encapsulation of implementation detail to the > latter group is less important than the former, and can be handled by > convention. Whereas other users of your

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

> No, sorry, I don't agree with you. > Current situation forces us to generate huge source files or write each > type in its own submodule/file. IMO it is very naturally to have a need to > protect access to some details *even* in the same file(please find David > Sweeris's answer in previous

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

On Fri, Feb 17, 2017 at 3:46 PM, Charlie Monroe wrote: > > On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu wrote: > >> On Fri, Feb 17, 2017 at 12:45

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

> On Feb 17, 2017, at 11:25 AM, Vladimir.S wrote: > > On 17.02.2017 20:16, David Sweeris via swift-evolution wrote: >> >> >> >> Sent from my iPhone >>> On Feb 17, 2017, at 01:02, Rien wrote: >>> >>> On 17 Feb 2017, at 03:36, David Sweeris via

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

On 17.02.2017 20:16, David Sweeris via swift-evolution wrote: Sent from my iPhone On Feb 17, 2017, at 01:02, Rien wrote: On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution wrote: On Feb 16, 2017, at 14:34, Slava Pestov via

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

On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu wrote: > On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S wrote: > >> On 17.02.2017 20:48, Xiaodi Wu wrote: >> >>> What you are really asking for is a way of flexibly designating a "unit >>> of >>> code" within a

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

On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S wrote: > On 17.02.2017 20:48, Xiaodi Wu wrote: > >> What you are really asking for is a way of flexibly designating a "unit of >> code" within a module, for which the general solution is submodules. The >> objection is that, instead

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

On 17.02.2017 20:48, Xiaodi Wu wrote: What you are really asking for is a way of flexibly designating a "unit of code" within a module, for which the general solution is submodules. The objection is that, instead of tackling that issue, these are suggestions to invent ad-hoc units of code (scope

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

> On Feb 17, 2017, at 9:48 AM, Xiaodi Wu via swift-evolution > wrote: > > What you are really asking for is a way of flexibly designating a "unit of > code" within a module, for which the general solution is submodules. The > objection is that, instead of tackling

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

What you are really asking for is a way of flexibly designating a "unit of code" within a module, for which the general solution is submodules. The objection is that, instead of tackling that issue, these are suggestions to invent ad-hoc units of code (scope + extensions only in the same file,

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

Sent from my iPhone > On Feb 17, 2017, at 01:02, Rien wrote: > > >> On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution >> wrote: >> >> >>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >>>

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

On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote: On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution > wrote: True, what I meant was a wider feedback - let's face it, there are many more Swift developers now

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

> On 16 Feb 2017, at 23:34, Slava Pestov via swift-evolution > wrote: > > While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary

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

> On Feb 17, 2017, at 9:29 AM, Slava Pestov wrote: > > >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution >> > wrote: >> >> True, what I meant was a wider feedback - let's face it, there are many

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

> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution > wrote: > > True, what I meant was a wider feedback - let's face it, there are many more > Swift developers now than 2 years ago. > > My objection is not to the documentation itself, but to the

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

True, what I meant was a wider feedback - let's face it, there are many more Swift developers now than 2 years ago. My objection is not to the documentation itself, but to the fact that I'm unnecessarily exposing an internal implementation detail to the rest of the module. Being able to hide

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

That blog post starts out right away to say that it's a response to community feedback. Moreover, the scenario you describe was just as possible in 2014 as it is now. Finally, then as now, it's unclear why you consider documentation to be "not pretty." After all, your reader would need to consult

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

I'm aware of this, but that's fairly a long time ago - before Swift was open source and had community feedback and before Swift was used widely among developers. To me, real-world use of the language has shown some flaws of missing a protected access control, mainly having to decide between

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

https://developer.apple.com/swift/blog/?id=11 > On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution > wrote: > > How about removing fileprivate, getting Swift 2 meaning of private (as most > people here now suggest) and add additional @protected

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

How about removing fileprivate, getting Swift 2 meaning of private (as most people here now suggest) and add additional @protected annotation for those who want a more fine-grained solution: @protected private - members accessable only from the class/struct/enum/... and their extensions within

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

Sent from my iPad > On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >> wrote: >> >> While we’re bikeshedding, I’m going to add my two cents.

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

> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution > wrote: > > While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary

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

> On Feb 16, 2017, at 4:51 PM, Slava Pestov wrote: > >> >> On Feb 16, 2017, at 4:50 PM, Slava Pestov > > wrote: >> >>> >>> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution >>>

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

> On Feb 16, 2017, at 4:50 PM, Slava Pestov wrote: > >> >> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution >> > wrote: >> >>> >>> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution >>>

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

> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution > wrote: > >> >> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution >> > wrote: >> >> >>> On Feb 16, 2017, at 4:28 PM, Matthew

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

> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution > wrote: > > >> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> As I have said elsewhere, I think the

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

> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution > > wrote: > > As I have said elsewhere, I think the mental anguish mostly derives from the > fact that scoped private is not the right “default” in a language that

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

> On Feb 16, 2017, at 4:55 PM, John McCall via swift-evolution > wrote: > >> On Feb 16, 2017, at 5:42 PM, Sean Heber via swift-evolution >> wrote: >> Honestly I really think this should be seriously considered. I do use >> private and

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

The primary point of access modifiers is communication, with the secondary point of something like ‘internal’ or ‘final’ to be compiler optimization. Other languages do just fine with just having naming conventions for implementation details, rather than having the compiler enforce that

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

> On Feb 16, 2017, at 5:42 PM, Sean Heber via swift-evolution > wrote: > Honestly I really think this should be seriously considered. I do use private > and fileprivate and such myself *because it’s there* and as a result it feels > like I should - but I shudder to

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

Honestly I really think this should be seriously considered. I do use private and fileprivate and such myself *because it’s there* and as a result it feels like I should - but I shudder to think how much brainpower I’ve wasted(?) on deciding which one to use when. I strongly suspect that the

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

While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat because this might be controversial here. I think both ‘private’ and ‘fileprivate’ are unnecessary complications that only serve to clutter the language. It would make a lot more sense to just have internal and public

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

> On Feb 15, 2017, at 1:34 AM, Dietmar Planitzer via swift-evolution > wrote: > > I do like approach #2. It would play well with extensions, look very familiar > to how private works in other main stream languages and it wouldn’t get in > the way of a possible

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

I am glad you mention the "protected" scope. For me the private keyword is mostly just frustrating, precisely because I expect it to act in the way you describe "protected" - but it doesn't. This is probably because all of projects at my organisation (regardless of language) have files of about

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

On 16.02.2017 10:14, Goffredo Marocchi via swift-evolution wrote: I think it would be a step back as it again oversimplifies access control IMHO. If we touch access control we should aim to improve it from both a library implementation point of view but for a user point of view as well. +1. I

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

I think it would be a step back as it again oversimplifies access control IMHO. If we touch access control we should aim to improve it from both a library implementation point of view but for a user point of view as well. Sent from my iPhone > On 16 Feb 2017, at 06:20, Chris Lattner via

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

On Feb 14, 2017, at 11:46 PM, Jean-Daniel via swift-evolution wrote: >>> Keeping with the spirit of Swift and staying consistent with its design, I >>> see two plausible meanings for private: >>> >>> Private could mean either: ... >>> (2) accessible only to the

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

> On Feb 15, 2017, at 4:16 PM, David Hart wrote: > > >> On 15 Feb 2017, at 23:15, Matthew Johnson > > wrote: >> >>> >>> On Feb 15, 2017, at 4:12 PM, David Hart >> >

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

> On 15 Feb 2017, at 23:15, Matthew Johnson wrote: > >> >> On Feb 15, 2017, at 4:12 PM, David Hart > > wrote: >> >>> >>> On 15 Feb 2017, at 16:31, Matthew Johnson >>

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

> On Feb 15, 2017, at 4:12 PM, David Hart wrote: > >> >> On 15 Feb 2017, at 16:31, Matthew Johnson > > wrote: >> >> >>> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution >>>

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

> On 15 Feb 2017, at 16:31, Matthew Johnson wrote: > > >> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution >> > wrote: >> >> >>> On Feb 14, 2017, at 3:20 AM, David Hart

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

> On Feb 15, 2017, at 5:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution >> wrote: >> >> Keeping with the spirit of Swift and staying consistent with its design, I

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

"Either keep it or drop it, but don't keep fiddling with it." sums up my position well. On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org>

  1   2   >