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

[Goffredo Marocchi via swift-evolution]

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  
>>> 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 those two protocols cannot 
>>> be extended, should we not be looking at some generally available mechanism 
>>> to prevent extensibility of any type?
>>> 
>>> And, I am not talking visibility here, just extensibility ; somehow those 
>>> two concerns are often conflated and, I believe, this is the cause of much 
>>> of the "lively" discussion on visibility specifiers.
>> 
>> This is imho more of an issue with ABI and resiliency. If I can create an 
>> extension which adds a method to a type, and that type gains a method with 
>> that same signature in a later release, what is the behavior?
> 
> Extension methods are lexically scoped and statically dispatched, so existing 
> code will not be affected by the addition of the new method. New code will 
> call whichever method is visible, or if both are visible in a given lexical 
> scope and overload resolution rules cannot pick an unambiguous winner, the 
> code will no longer type check.

This situation seems pretty messy as, say with a binary framework one day, it 
may lead to someone conforming to a protocol and implementing a method that 
will never be called as it is silently overriding a default method only 
declared in an extension... and there are no warnings for that. 
I think that if the protocol or a protocol extension provides a default 
implementation a class conforming to it not being allowed to override it may 
actually help.

Not to mention how for many protocols should be abstract contracts not 
implementations, I cannot be the only one that enjoys returning to a situation 
where the code being executed depends on how I dress my instance and not what 
my instance is:
...objA is an instance of ClassA that conforms to ProtoA which also has a 
myMethod method and an extension which provides a default implementation of it.

objA.myMethod() 

vs

(objA as ProtoA).myMethod()

When did casting an instance to another type changes what code gets executed 
became ok and good practice again :)?

Default methods are serving a purpose and are allowing code sharing across 
structs, but IMHO they cause more harm than good with classes and OOP design 
while not being a necessary condition for POP either.


> 
> The situation is messier with extensions that add protocol conformances. 
> Right now we don’t do a good job of dealing with duplicate conformances 
> because we assume in several places in the compiler and runtime that they can 
> be looked up globally. We plan on addressing at least some of this.
> 
> Slava
> 
>> 
>>> 
 In C++ terms, it would be when I want some other class to have friend 
 access to a function/data, but for it not to be arbitrarily accessible by 
 subtypes
>>> 
>>> Indeed. I do wonder if some folks approach visibility control as an 
>>> exercise in "what can I see" whereas, demonstrated by C++ friends, it 
>>> becomes obvious that it is more about "what do I want to allow to be seen"
>>> 
>>> 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 new access modifiers 
>> (including possible submodule functionality) + extensibility modifiers are 
>> considered holistically. 
>> 
>> For instance, if there is a feature that allows something comparable to 
>> ‘friend’ level access, a restrictive private makes a lot more sense than one 
>> with exceptions allowing access to subtypes, within the same file, to 
>> extensions, etc. A restrictive, scoped private would be what you use to 
>> protect the invariants of your type, with less protected methods given to 
>> allow extensions and internal modification safely.
>> 
>> But without a submodule or similar access level, we need a “fileprivate” 
>> level access (renamed to ‘private’ or not) to make sure code needing a 
>> higher level of access can get it, by being embedded in the same file.
>> 
>>> OK, how does this sound?
>>> 
>>> Extend the 'final' concept, currently used only in classes, to protect any, 
>>> non-protocol, type from being extended.
>> 
>> The extension mechanism, both being able to add new methods and to conform 
>> an existing class to a protocol retroactively, is absurdly powerful. It 
>> doesn’t offer any privileged manipulation of types today that would give a 
>> safety related reason to restrict it. I’d be reluctant to let someone take 
>> that away from me personally without a strong language-level justification 
>> (such as needing to restrict it partial

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

[Slava Pestov via swift-evolution]

> 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 AnyObject, which appear to be protected by some deep and dark 
>> mechanism within the compiler.  So, just as those two protocols cannot be 
>> extended, should we not be looking at some generally available mechanism to 
>> prevent extensibility of any type?
>> 
>> And, I am not talking visibility here, just extensibility ; somehow those 
>> two concerns are often conflated and, I believe, this is the cause of much 
>> of the "lively" discussion on visibility specifiers.
> 
> This is imho more of an issue with ABI and resiliency. If I can create an 
> extension which adds a method to a type, and that type gains a method with 
> that same signature in a later release, what is the behavior?

Extension methods are lexically scoped and statically dispatched, so existing 
code will not be affected by the addition of the new method. New code will call 
whichever method is visible, or if both are visible in a given lexical scope 
and overload resolution rules cannot pick an unambiguous winner, the code will 
no longer type check.

The situation is messier with extensions that add protocol conformances. Right 
now we don’t do a good job of dealing with duplicate conformances because we 
assume in several places in the compiler and runtime that they can be looked up 
globally. We plan on addressing at least some of this.

Slava

> 
>> 
>>> In C++ terms, it would be when I want some other class to have friend 
>>> access to a function/data, but for it not to be arbitrarily accessible by 
>>> subtypes
>> 
>> Indeed. I do wonder if some folks approach visibility control as an exercise 
>> in "what can I see" whereas, demonstrated by C++ friends, it becomes obvious 
>> that it is more about "what do I want to allow to be seen"
>> 
>> 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 new access modifiers 
> (including possible submodule functionality) + extensibility modifiers are 
> considered holistically. 
> 
> For instance, if there is a feature that allows something comparable to 
> ‘friend’ level access, a restrictive private makes a lot more sense than one 
> with exceptions allowing access to subtypes, within the same file, to 
> extensions, etc. A restrictive, scoped private would be what you use to 
> protect the invariants of your type, with less protected methods given to 
> allow extensions and internal modification safely.
> 
> But without a submodule or similar access level, we need a “fileprivate” 
> level access (renamed to ‘private’ or not) to make sure code needing a higher 
> level of access can get it, by being embedded in the same file.
> 
>> OK, how does this sound?
>> 
>> Extend the 'final' concept, currently used only in classes, to protect any, 
>> non-protocol, type from being extended.
> 
> The extension mechanism, both being able to add new methods and to conform an 
> existing class to a protocol retroactively, is absurdly powerful. It doesn’t 
> offer any privileged manipulation of types today that would give a safety 
> related reason to restrict it. I’d be reluctant to let someone take that away 
> from me personally without a strong language-level justification (such as 
> needing to restrict it partially to meet ABI/resiliency requirements)
> 
> -DW
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> 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 new access modifiers 
> (including possible submodule functionality) + extensibility modifiers are 
> considered holistically. 
> 
> For instance, if there is a feature that allows something comparable to 
> ‘friend’ level access, a restrictive private makes a lot more sense than one 
> with exceptions allowing access to subtypes, within the same file, to 
> extensions, etc. A restrictive, scoped private would be what you use to 
> protect the invariants of your type, with less protected methods given to 
> allow extensions and internal modification safely.
> 
> But without a submodule or similar access level, we need a “fileprivate” 
> level access (renamed to ‘private’ or not) to make sure code needing a higher 
> level of access can get it, by being embedded in the same file.

As you can see, I've already started a thread to try and nail down exactly what 
we have already got, in an attempt to find where the holes are.

> The extension mechanism, both being able to add new methods and to conform an 
> existing class to a protocol retroactively, is absurdly powerful. It doesn’t 
> offer any privileged manipulation of types today that would give a safety 
> related reason to restrict it. I’d be reluctant to let someone take that away 
> from me personally without a strong language-level justification (such as 
> needing to restrict it partially to meet ABI/resiliency requirements)

I am hoping by "starting over" with an analysis of requirements, step by step, 
that we can clear away some of the confusion that has grown up and lay down 
agreed requirements for the way ahead.

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

> 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 those two protocols cannot be 
> extended, should we not be looking at some generally available mechanism to 
> prevent extensibility of any type?
> 
> And, I am not talking visibility here, just extensibility ; somehow those two 
> concerns are often conflated and, I believe, this is the cause of much of the 
> "lively" discussion on visibility specifiers.

This is imho more of an issue with ABI and resiliency. If I can create an 
extension which adds a method to a type, and that type gains a method with that 
same signature in a later release, what is the behavior?

> 
>> In C++ terms, it would be when I want some other class to have friend access 
>> to a function/data, but for it not to be arbitrarily accessible by subtypes
> 
> Indeed. I do wonder if some folks approach visibility control as an exercise 
> in "what can I see" whereas, demonstrated by C++ friends, it becomes obvious 
> that it is more about "what do I want to allow to be seen"
> 
> 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 new access modifiers 
(including possible submodule functionality) + extensibility modifiers are 
considered holistically. 

For instance, if there is a feature that allows something comparable to 
‘friend’ level access, a restrictive private makes a lot more sense than one 
with exceptions allowing access to subtypes, within the same file, to 
extensions, etc. A restrictive, scoped private would be what you use to protect 
the invariants of your type, with less protected methods given to allow 
extensions and internal modification safely.

But without a submodule or similar access level, we need a “fileprivate” level 
access (renamed to ‘private’ or not) to make sure code needing a higher level 
of access can get it, by being embedded in the same file.

> OK, how does this sound?
> 
> Extend the 'final' concept, currently used only in classes, to protect any, 
> non-protocol, type from being extended.

The extension mechanism, both being able to add new methods and to conform an 
existing class to a protocol retroactively, is absurdly powerful. It doesn’t 
offer any privileged manipulation of types today that would give a safety 
related reason to restrict it. I’d be reluctant to let someone take that away 
from me personally without a strong language-level justification (such as 
needing to restrict it partially to meet ABI/resiliency requirements)

-DW
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

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 swift-evolution 
>  wrote:
> 
> 
>>> Le 21 févr. 2017 à 05:21, David Waite  a 
>>> écrit :
>>> 
>>> The only other option that might be useful is something like 'internal 
>>> extensible' to limit visibility for extensible members to the current 
>>> module.
>> If a type is extensible by other modules at all, I prefer that to be spelled 
>> “public”.
> 
> Indeed, I could agree with that but…
> 
> Before 'open' was added to indicate extensibility of a publicly visible 
> class, we used to have 'public' to indicate that the class was visible 
> anywhere and 'final' to restrict inheritance/overriding.
> 
> With classes, 'final' was good enough to indicate that a type and/or its 
> members should not be extensible.
> 
> 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 those two protocols cannot be 
> extended, should we not be looking at some generally available mechanism to 
> prevent extensibility of any type?
> 
> And, I am not talking visibility here, just extensibility ; somehow those two 
> concerns are often conflated and, I believe, this is the cause of much of the 
> "lively" discussion on visibility specifiers.
> 
>> In C++ terms, it would be when I want some other class to have friend access 
>> to a function/data, but for it not to be arbitrarily accessible by subtypes
> 
> Indeed. I do wonder if some folks approach visibility control as an exercise 
> in "what can I see" whereas, demonstrated by C++ friends, it becomes obvious 
> that it is more about "what do I want to allow to be seen"
> 
> Is there not a value in forking this discussion into which keywords are truly 
> about visibility control and which are about extensibility control?
> 
>> I believe the critical piece of designing access levels is for the levels to 
>> document the intent of the developer specifying the access level. Does 
>> “extensible” indicate that the designer of the library wanted a certain kind 
>> of access - or that the compiler maybe gave an error at some point when it 
>> was “private”?
> 
> This is somewhere where I have to bring up my learning and experience with 
> other languages. Albeit only with classes, private always meant what it said 
> on the tin - from outside of a class, it doesn't exist, don't touch!
> 
> Which is why I am very wary of reverting file scope to private.
> 
> 'fileprivate' is a keyword that allows, not extensibility but visibility.
> 
> Extensibility control for non-class types is more akin to using or not using 
> 'final' to control inheritance/overriding with classes.
> 
> Maybe, instead of looking at extending visibility by adding yet another 
> visibility specifier (extensible), we should be looking at adding a specifier 
> that limits extensibility for any type?
> 
> This would be additive and would have the advantage of not breaking so much 
> code.
> 
> OK, how does this sound?
> 
> Extend the 'final' concept, currently used only in classes, to protect any, 
> non-protocol, type from being extended.
> 
> That way, folks who are not so "purist" about access control can continue as 
> before, leaving those of us who want that control to be able to exercise it.
> 
> So, for example :
> 
> final struct DontExtendMe
> {
>  …
> }
> 
> extension DontExtendMe // error : final type cannot be extended
> {
>  …
> }
> 
> I am not suggesting that 'final' should be applicable to members of non-class 
> types. Members of class types should continue to be markable as 'final' for 
> inheritance control reasons.
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> Le 21 févr. 2017 à 05:21, David Waite  a écrit :
> 
>> The only other option that might be useful is something like 'internal 
>> extensible' to limit visibility for extensible members to the current module.
> If a type is extensible by other modules at all, I prefer that to be spelled 
> “public”.

Indeed, I could agree with that but…

Before 'open' was added to indicate extensibility of a publicly visible class, 
we used to have 'public' to indicate that the class was visible anywhere and 
'final' to restrict inheritance/overriding.

With classes, 'final' was good enough to indicate that a type and/or its 
members should not be extensible.

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 those two protocols cannot be 
extended, should we not be looking at some generally available mechanism to 
prevent extensibility of any type?

And, I am not talking visibility here, just extensibility ; somehow those two 
concerns are often conflated and, I believe, this is the cause of much of the 
"lively" discussion on visibility specifiers.

> In C++ terms, it would be when I want some other class to have friend access 
> to a function/data, but for it not to be arbitrarily accessible by subtypes

Indeed. I do wonder if some folks approach visibility control as an exercise in 
"what can I see" whereas, demonstrated by C++ friends, it becomes obvious that 
it is more about "what do I want to allow to be seen"

Is there not a value in forking this discussion into which keywords are truly 
about visibility control and which are about extensibility control?

> I believe the critical piece of designing access levels is for the levels to 
> document the intent of the developer specifying the access level. Does 
> “extensible” indicate that the designer of the library wanted a certain kind 
> of access - or that the compiler maybe gave an error at some point when it 
> was “private”?

This is somewhere where I have to bring up my learning and experience with 
other languages. Albeit only with classes, private always meant what it said on 
the tin - from outside of a class, it doesn't exist, don't touch!

Which is why I am very wary of reverting file scope to private.

'fileprivate' is a keyword that allows, not extensibility but visibility.

Extensibility control for non-class types is more akin to using or not using 
'final' to control inheritance/overriding with classes.

Maybe, instead of looking at extending visibility by adding yet another 
visibility specifier (extensible), we should be looking at adding a specifier 
that limits extensibility for any type?

This would be additive and would have the advantage of not breaking so much 
code.

OK, how does this sound?

Extend the 'final' concept, currently used only in classes, to protect any, 
non-protocol, type from being extended.

That way, folks who are not so "purist" about access control can continue as 
before, leaving those of us who want that control to be able to exercise it.

So, for example :

final struct DontExtendMe
{
  …
}

extension DontExtendMe // error : final type cannot be extended
{
  …
}

I am not suggesting that 'final' should be applicable to members of non-class 
types. Members of class types should continue to be markable as 'final' for 
inheritance control reasons.

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

> 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 subtypes/extensions in other files
> 
> The only other option that might be useful is something like 'internal 
> extensible' to limit visibility for extensible members to the current module.
If a type is extensible by other modules at all, I prefer that to be spelled 
“public”.

> Sorry, I would still like to see a waterproof argument for what is presently 
> called fileprivate ; with the above scopes, I simply can't see the need. 
> Unless you can convince me, that is ;-)

 In C++ terms, it would be when I want some other class to have friend access 
to a function/data, but for it not to be arbitrarily accessible by subtypes

I believe the critical piece of designing access levels is for the levels to 
document the intent of the developer specifying the access level. Does 
“extensible” indicate that the designer of the library wanted a certain kind of 
access - or that the compiler maybe gave an error at some point when it was 
“private”?

-DW
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

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?
> 
> To provide access for internals of my type for code in current file only,
> and don't for any extension/subtype in other files. I.e. 'friend' classes in 
> the same file, but don't want to provide any details out of the file.

Ah, I can see what you're getting at there. How about the idea of using nested 
types?

> I assume the 'extensible' modifier should be limited by current module only.
> I.e. in my understanding 'extensible' : "in current file and in 
> subtypes/extensions in other files inside the module". I believe there is a 
> consensus that Swift should not export "private" API out of the module.

My thinking about extensible is that it is not for truly private stuff ; more 
for extending the same idea of protected access for classes to the more 
Swiftier concept of extensions.

--
Joanna Carter
Carter Consulting
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 inside just other
types("friend" types), not extending types. So, in this case we want
something like fileprivate+extensible if we want also share details
for extending types in other files. And so, IMO, 'extensible' should
means 'accessible as for private but also in extending types AND
INSIDE CURRENT FILE", or we need one more access modifier.


I think that was what I was intending. If 'extensible' was type-based,
then, surely, whether the 'friend' was in the same file/module or
whatever, the accessibility would be the same?


Also, there is a common(IMO) opinion in the list that we should rename
fileprivate to private as in Swift2.


I'm not sure why ; with 'extensible' available to code within the same
file, why would you still need fileprivate anywy?


To provide access for internals of my type for code in current file only,
and don't for any extension/subtype in other files. I.e. 'friend' classes 
in the same file, but don't want to provide any details out of the file.





So, I believe this will be optimal minimum of access modifiers set:

public: outside of module internal: anywhere inside module private:
anywhere in current file scoped(hidden,*or other keyword*): as current
'private', only inside declared type extensible : in current file and
in subtypes/extensions in other files


Otherwise known in my language as :

public - anywhere internal - anywhere inside the module private - only
inside current type extensible - in current file and in
subtypes/extensions in other files

The only other option that might be useful is something like 'internal
extensible' to limit visibility for extensible members to the current
module.


I assume the 'extensible' modifier should be limited by current module only.
I.e. in my understanding 'extensible' : "in current file and in 
subtypes/extensions in other files inside the module". I believe there is a 
consensus that Swift should not export "private" API out of the module.




Sorry, I would still like to see a waterproof argument for what is
presently called fileprivate ; with the above scopes, I simply can't see
the need. Unless you can convince me, that is ;-) -- Joanna Carter
Carter Consulting



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 11:02 AM, David Hart  wrote:
> 
> 
>> On 20 Feb 2017, at 16:43, Matthew Johnson > > wrote:
>> 
>> 
>>> On Feb 20, 2017, at 12:31 AM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> 
 On 20 Feb 2017, at 00:52, Tony Arnold via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution 
> mailto:swift-evolution@swift.org>> 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 
 about it. I think Chris’ second suggestion fits my idea of a reasonable 
 “Default” level of privacy when starting out, and fits the model of 
 progressive disclosure as you so excellently pointed out.
 
 Is this something that should go through a proper Proposal? Is someone 
 doing this already? I’d like to help/contribute if it is.
>>> 
>>> Chris' second suggestion was dropped by Chris himself after we discussed 
>>> the disadvantages it adds. I am already working on a proposal to revert to 
>>> Swift 2's private and it should be ready soon. 
>> 
>> Since you’re already drafting a proposal I will not draft the one I was 
>> thinking of.
> 
> My proposal will represent my point of view (only one file-based private), 
> but I am mentioning your suggestions in the Alternatives considered section 
> to open debate during vote and so that the core team can decide amongst 
> multiple alternatives.
> 
> By the way, do you want to send me part of your proposal so I can copy/paste 
> some of your arguments in the Alternatives considered section?
> 
> I’d be better if the proposal represented well the different community 
> opinions :)

Agree.  I’d be happy to collaborate on helping to fill out the alternative 
section.  I’ll write something up and send it off list for you to incorporate 
as desired.

> 
> David.
> 
>>> 
 thanks,
 
 
 Tony
 
 
 
 --
 Tony Arnold
 +61 411 268 532
 http://thecocoabots.com/ 
 
 ABN: 14831833541
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> 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 inside 
> just other types("friend" types), not extending types.
> So, in this case we want something like fileprivate+extensible if we want 
> also share details for extending types in other files.
> And so, IMO, 'extensible' should means 'accessible as for private but also in 
> extending types AND INSIDE CURRENT FILE", or we need one more access modifier.

I think that was what I was intending. If 'extensible' was type-based, then, 
surely, whether the 'friend' was in the same file/module or whatever, the 
accessibility would be the same?

> Also, there is a common(IMO) opinion in the list that we should rename 
> fileprivate to private as in Swift2.

I'm not sure why ; with 'extensible' available to code within the same file, 
why would you still need fileprivate anywy?

> So, I believe this will be optimal minimum of access modifiers set:
> 
> public: outside of module
> internal: anywhere inside module
> private: anywhere in current file
> scoped(hidden,*or other keyword*): as current 'private', only inside declared 
> type
> extensible : in current file and in subtypes/extensions in other files

Otherwise known in my language as :

public - anywhere
internal - anywhere inside the module
private - only inside current type
extensible - in current file and in subtypes/extensions in other files

The only other option that might be useful is something like 'internal 
extensible' to limit visibility for extensible members to the current module.

Sorry, I would still like to see a waterproof argument for what is presently 
called fileprivate ; with the above scopes, I simply can't see the need. Unless 
you can convince me, that is ;-)
--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> 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 
>>>  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 provide those examples? This thread has been actively discussed 
>>> for close to a week now, so it would be good to do something concrete about 
>>> it. I think Chris’ second suggestion fits my idea of a reasonable “Default” 
>>> level of privacy when starting out, and fits the model of progressive 
>>> disclosure as you so excellently pointed out.
>>> 
>>> Is this something that should go through a proper Proposal? Is someone 
>>> doing this already? I’d like to help/contribute if it is.
>> 
>> Chris' second suggestion was dropped by Chris himself after we discussed the 
>> disadvantages it adds. I am already working on a proposal to revert to Swift 
>> 2's private and it should be ready soon. 
> 
> Since you’re already drafting a proposal I will not draft the one I was 
> thinking of.

My proposal will represent my point of view (only one file-based private), but 
I am mentioning your suggestions in the Alternatives considered section to open 
debate during vote and so that the core team can decide amongst multiple 
alternatives.

By the way, do you want to send me part of your proposal so I can copy/paste 
some of your arguments in the Alternatives considered section?

I’d be better if the proposal represented well the different community opinions 
:)

David.

>> 
>>> thanks,
>>> 
>>> 
>>> Tony
>>> 
>>> 
>>> 
>>> --
>>> Tony Arnold
>>> +61 411 268 532
>>> http://thecocoabots.com/
>>> 
>>> ABN: 14831833541
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> Le 20 févr. 2017 à 16:59, Dimitri Racordon  a 
> écrit :
> 
> 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 
> want to spare a thought for people in large teams. I do recognise the issue, 
> I just don’t think complicated access control is the silver bullet. Hence I’d 
> rather favour simplicity of the language over expressivity of its access 
> control.

Which is why I am suggesting simple access control, rather than the 
complications we are getting now.

> If ill-advised users want to do silly things with your awesome type, they 
> will. I’ll bet we could find one person who thinks using reflection is such a 
> clever way to bypass these so-called private properties.

Well, at least if your classes don't inherit from NSObject, reflection won't do 
them much good ;-)

> Yet if you google "private vs protected", the first 5 links are stackoverflow 
> questions on the subject, and the rest of the first page are blog posts like 
> “Pragmatism over Theory: Protected vs Private”. Despite decades of OO, those 
> notions are still confusing for many people, and are intimidating for 
> newcomers.

I suppose the problem is that so many "newcomers" never went to college and 
learnt the basics. They saw the promise of fame and fortune(?) via the 
AppStore, went out and got themselves a Mac and started coding without the 
faintest idea of what a class or a struct are, never mind what scope to use.

>> Ah, hang on, that makes…  one visibility to learn ;-)
> 
> Nope, it doesn’t. Extensible wouldn’t restrict the visibility as tightly as I 
> described.

Does it really need that degree of control?

> That said, that list was a shameless exaggeration more than a critique of 
> your proposition.

;-)

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matt Whiteside via swift-evolution]

> On Feb 20, 2017, at 03:43, Ross O'Brien via swift-evolution 
>  wrote:
> 
> Possibly the dependence on filesystem structure feels restrictive to some 
> developers.

I agree with this.  For example in the Xcode 'symbol navigator’ view, where you 
can view all the classes/structs in your project hierarchically and 
alphabetically, you aren’t dealing with files at all, and from that point of 
view, fileprivate is just confusing.

> It seems to me that in this four-tier structure (public, internal, 
> fileprivate, private) that a significant number of developers think that's 
> one, maybe two tiers too many (the system should be simplified), and for 
> others that's one, maybe two tiers too few (fileprivate is doing too much, 
> and a submodule tier would relieve that pressure).

I think the four-tier structure is too many.  My understanding is that: public 
= everybody can get to it, internal = only those within the module can get to 
it, but beyond that, i.e., when and for what purpose one should use fileprivate 
vs private, it starts to get foggy to me.

-Matt

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 years, I can say that, from real 
world experience, large code files are a $&§*% nightmare.

They are an absolute dog to maintain if you are working in a team environment 
because, if one person wants to work on one extension and another wants to work 
on a second, the source control implications are horrendous with merges, 
conflicts, etc, all over the shop.

Of course, if you are a lone developer, then it's up to you how long you take 
to find bugs and fix them and, as for source control, there is no problem with 
all those merges and conflicts. Just spare a thought for the larger teams.


compared to additional complexity induced by more subtle access control 
syntax/semantics. fileprivate has the privilege to be easy to understand by 
*anyone*; extensible, scoped, protected and the likes are not.


Most developers who any experience in any OO language other than Objective-C and Swift 
are usually extremely well versed in the "standard" class visibilities ; it's 
one of those things you get taught in the first couple of lectures on any good 
programming course.


Also, I don’t think the expressivity of access control should cover every 
single case:
* What if I want another type to access my internal properties?


Use 'extensible' on the properties you want to expose


* What if I want another type to access a subset of my internal properties?


Use 'extensible' on the properties you want to expose


* What if I want another type to access a subset of my internal properties in 
read-only?


Use 'extensible' on the properties you want to expose


* What if I want another *function* to access my internal properties?


Use 'extensible' on the properties you want to expose

Ah, hang on, that makes…  one visibility to learn ;-)


I may even agree that in these instances a super-fine-tuned access control 
might have saved few hours of work, but nobody seem to consider the additional 
cost of having those in the first place. If it takes days for (in)experienced 
users to understand the meaning of an access control modifier,


private - only accessible in the declaring entity
extensible - accessible as for private but also in extending types
internal - accessible anywhere within a module
public - accessible anywhere


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 
inside just other types("friend" types), not extending types.
So, in this case we want something like fileprivate+extensible if we want 
also share details for extending types in other files.
And so, IMO, 'extensible' should means 'accessible as for private but also 
in extending types AND INSIDE CURRENT FILE", or we need one more access 
modifier.


Also, there is a common(IMO) opinion in the list that we should rename 
fileprivate to private as in Swift2.


So, I believe this will be optimal minimum of access modifiers set:

public: outside of module
internal: anywhere inside module
private: anywhere in current file
scoped(hidden,*or other keyword*): as current 'private', only inside 
declared type

extensible : in current file and in subtypes/extensions in other files



You really think it takes days to learn four visibilities? I am truly shocked!


plus hours and hours of debating with your team whether some 
type/function/property should be private, file private, type private, 
extensible private, module private, etc. the potential time saved by having 
access control is lost by having to define it properly.


Of course, if you only use the above four visibilities, the discussions are 
much shorter ;-)

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 tend to use the Swift idiom of declaring a type, and then 
> declaring an extension each protocol conformance, and sometimes that means 
> putting a property in the type rather than the extension and that requires 
> fileprivate. That's not ideal, but if there were an idiomatically neater way 
> to declare a private property in the extension and have Swift recognise that 
> property as being part of the type but contextually linked only to that 
> protocol conformance then that would be good.
> 
> 'Fileprivate' makes files equivalent to submodules, and this can lead to 
> undesirably long files. Possibly the dependence on filesystem structure feels 
> restrictive to some developers. It seems to me that in this four-tier 
> structure (public, internal, fileprivate, private) that a significant number 
> of developers think that's one, maybe two tiers too many (the system should 
> be simplified), and for others that's one, maybe two tiers too few 
> (fileprivate is doing too much, and a submodule tier would relieve that 
> pressure).
> 
> I think a submodule access level has been suggested a lot of times, but I 
> don't think anyone's formally proposed a possible syntax for it.
> 
> 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 moment I think there are four ways - have 
> I missed any?
> 
> 1) Submodules correspond directly to file directories (simple, but possibly 
> binds a project too closely to an operating system, inflexible for systems 
> like Git).
> 2) The submodule has an access control file which lists its member files (as 
> modules do)
> 3) Files opt-in to membership of a submodule (e.g. 'memberOf Submodule' just 
> below 'import Foundation')
> 4) Files 'friend' other files into their submodule, somehow.
> 
> Worth noting: the latter three of these suggestions don't implicitly prevent 
> a file from being a member of more than one submodule.
> 
> I don't have my own answer to this question yet, but I think discussion of it 
> will help decide whether submodules are a practical possibility. If they are, 
> perhaps there's justification for fileprivate; if not, perhaps reverting to 
> Swift 2's private is better.

Thanks for bringing up submodules again!

I think a well-designed, flexible submodule mechanism would be very nice to 
have.  There are many issues that should be addressed along the way.  Here are 
just a few:

* How do we define the files that make up a submodule? (as you point out)
* Are submodules hierarchical, allowing submodules to be nested inside of 
another submodule?
* How does a submodule specify visibility of a member that is not public but is 
available to the rest of the module (or perhaps just a parent submodule)?
* Can submodules have cross-dependencies?
* Should it be possible for users of a module to import only a submodule rather 
than the entire module?
* Should it be possible to compile submodules independently?
* How do submodules interact with whole module optimization?
* How do submodules address (or not address) namespacing?

The last question is somewhat important.  The design of submodules should not 
proceed without considering namespaces and whether or not submodules are 
intended to address this problem.  In some languages, code in another file can 
introduce new names into a namespace declared elsewhere (i.e. they are 
module-less).  Is this important?  Some people may want to have namespaces that 
are open to extension (which obviously submodules are not).  What are the use 
cases?  If we decide we don’t need namespaces that are open to extension then 
submodules may be a suitable mechanism for handling use cases sometimes 
addressed with namespaces.

One interesting thing to note is that if we do introduce submodules, especially 
if we introduce hierarchical submodules, then we have a pretty clean hierarchy 
of nested scopes.  We could even say that files are an anonymous submodule.  
The picture looks like this:

module
 |
grandparent submodule
 |
parent submodule
 |
submodule
 |
anonymous file submodule
 |
outer lexical scope
 |
inner lexical scope

If we go in this direction and we want to allow submodules to expose a member 
upwards to a containing submodule, but not to the rest of the module as a 
whole, we will need some kind of way to refer to the name of the containing 
submodule.  One logical way to do that is to simply parameterize `private` as 
some have suggested:

private // current lexical scope
private(OuterType) // imagine this: struct OuterType { struct InnerType { 
private(OtherType) var x = 42 } }
private(fi

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

[Dimitri Racordon via swift-evolution]

> 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 want to 
spare a thought for people in large teams. I do recognise the issue, I just 
don’t think complicated access control is the silver bullet. Hence I’d rather 
favour simplicity of the language over expressivity of its access control.

If ill-advised users want to do silly things with your awesome type, they will. 
I’ll bet we could find one person who thinks using reflection is such a clever 
way to bypass these so-called private properties.

> Most developers who any experience in any OO language other than Objective-C 
> and Swift are usually extremely well versed in the "standard" class 
> visibilities ; it's one of those things you get taught in the first couple of 
> lectures on any good programming course.

Yet if you google "private vs protected", the first 5 links are stackoverflow 
questions on the subject, and the rest of the first page are blog posts like 
“Pragmatism over Theory: Protected vs Private”. Despite decades of OO, those 
notions are still confusing for many people, and are intimidating for newcomers.

Besides, I think those results also illustrate my point about the 
time-consuming debates on what access level something should have.

> Ah, hang on, that makes…  one visibility to learn ;-)

Nope, it doesn’t. Extensible wouldn’t restrict the visibility as tightly as I 
described. That said, that list was a shameless exaggeration more than a 
critique of your proposition.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 
>>>  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 about 
>> it. I think Chris’ second suggestion fits my idea of a reasonable “Default” 
>> level of privacy when starting out, and fits the model of progressive 
>> disclosure as you so excellently pointed out.
>> 
>> Is this something that should go through a proper Proposal? Is someone doing 
>> this already? I’d like to help/contribute if it is.
> 
> Chris' second suggestion was dropped by Chris himself after we discussed the 
> disadvantages it adds. I am already working on a proposal to revert to Swift 
> 2's private and it should be ready soon. 

Since you’re already drafting a proposal I will not draft the one I was 
thinking of.

> 
>> thanks,
>> 
>> 
>> Tony
>> 
>> 
>> 
>> --
>> Tony Arnold
>> +61 411 268 532
>> http://thecocoabots.com/
>> 
>> ABN: 14831833541
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> 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, large code files are a $&§*% nightmare.

They are an absolute dog to maintain if you are working in a team environment 
because, if one person wants to work on one extension and another wants to work 
on a second, the source control implications are horrendous with merges, 
conflicts, etc, all over the shop.

Of course, if you are a lone developer, then it's up to you how long you take 
to find bugs and fix them and, as for source control, there is no problem with 
all those merges and conflicts. Just spare a thought for the larger teams.

> compared to additional complexity induced by more subtle access control 
> syntax/semantics. fileprivate has the privilege to be easy to understand by 
> *anyone*; extensible, scoped, protected and the likes are not.

Most developers who any experience in any OO language other than Objective-C 
and Swift are usually extremely well versed in the "standard" class 
visibilities ; it's one of those things you get taught in the first couple of 
lectures on any good programming course.

> Also, I don’t think the expressivity of access control should cover every 
> single case:
> * What if I want another type to access my internal properties?

Use 'extensible' on the properties you want to expose

> * What if I want another type to access a subset of my internal properties?

Use 'extensible' on the properties you want to expose

> * What if I want another type to access a subset of my internal properties in 
> read-only?

Use 'extensible' on the properties you want to expose

> * What if I want another *function* to access my internal properties?

Use 'extensible' on the properties you want to expose

Ah, hang on, that makes…  one visibility to learn ;-)

> I may even agree that in these instances a super-fine-tuned access control 
> might have saved few hours of work, but nobody seem to consider the 
> additional cost of having those in the first place. If it takes days for 
> (in)experienced users to understand the meaning of an access control modifier,

private - only accessible in the declaring entity
extensible - accessible as for private but also in extending types
internal - accessible anywhere within a module
public - accessible anywhere

You really think it takes days to learn four visibilities? I am truly shocked!

> plus hours and hours of debating with your team whether some 
> type/function/property should be private, file private, type private, 
> extensible private, module private, etc. the potential time saved by having 
> access control is lost by having to define it properly.

Of course, if you only use the above four visibilities, the discussions are 
much shorter ;-)

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dimitri Racordon via swift-evolution]

I think that fileprivate is fine, and that the drawback of having very large 
files is acceptable, compared to additional complexity induced by more subtle 
access control syntax/semantics. fileprivate has the privilege to be easy to 
understand by *anyone*; extensible, scoped, protected and the likes are not.

Also, I don’t think the expressivity of access control should cover every 
single case:
* What if I want another type to access my internal properties?
* What if I want another type to access a subset of my internal properties?
* What if I want another type to access a subset of my internal properties in 
read-only?
* What if I want another *function* to access my internal properties?
* …

I’m sure everybody can find good examples illustrating the above questions, and 
I’m sure some people already encountered similar situations. I may even agree 
that in these instances a super-fine-tuned access control might have saved few 
hours of work, but nobody seem to consider the additional cost of having those 
in the first place. If it takes days for (in)experienced users to understand 
the meaning of an access control modifier, plus hours and hours of debating 
with your team whether some type/function/property should be private, file 
private, type private, extensible private, module private, etc. the potential 
time saved by having access control is lost by having to define it properly.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Waldowski via swift-evolution]

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 it is now a, when the burden of proof was
ignored in the rush to add it to the language.

As you insist we spend our energies elsewhere, I meet more and more
people who are turned off by Swift because of arcana like fileprivate.
The language is 3 years old; it shouldn't have baggage like this.
"Similar but subtly different to another keyword by the addition of a
few letters of easily-confused spelling" is C++ to the tee.

No, I'll concede in the end it's just a papercut, albeit in the sea of
other paper cuts including compile times, generics limitations,
overcomplicating bridging, etc, etc. However, this is a battle for the
soul of the language as much as anything else is on Evolution. The
opinions of those who want to add an ill-considered keyword to solve
every problem are overrepresented; those for whom that pattern fatally
complicates the language are underrepresented, because they've already
stopped using Swift.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

> 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 moment I think there are four ways - have 
> I missed any?
> 
> 1) Submodules correspond directly to file directories (simple, but possibly 
> binds a project too closely to an operating system, inflexible for systems 
> like Git).
> 2) The submodule has an access control file which lists its member files (as 
> modules do)
> 3) Files opt-in to membership of a submodule (e.g. 'memberOf Submodule' just 
> below 'import Foundation')
> 4) Files 'friend' other files into their submodule, somehow.

For #4, my suggestion has been to add a single keyword ‘hidden’.  Marking 
something hidden means that things outside of the file can’t see it. 

public struct MyStruct {
var a:Int //This is ‘internal' 
hidden var b:Int //This is also ‘internal’, but is hidden, so 
is not visible outside the file
}

To let a file see the hidden items, you ‘import hidden’ instead of just 
‘import’:

import hidden MyStruct  //Now ‘b' is visible within this file

Because it is still internal, b is still only accessible within the module 
(even with ‘import hidden’).  If it was a ‘public hidden var’ or ‘open hidden 
var’ then it could be accessed via ‘import hidden’ outside the module as well.

Make sense?

I think this is the simplest way to get behavior similar to protected, friends, 
and submodules… all with swift’s file-based access approach.

Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> 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 access 
> control, and to have that, the access control modifiers should be powerful 
> and few do they are actually used. Right now we have private and fileprivate 
> and many people don't use them consistently because they are so similar. We 
> need only one private access control and I'm voting for fileprivate because 
> it is the one which is the simplest while still working well with Swift's 
> extension mechanisms.

But the problem is, fileprivate may work well with Swift's extension mechanism 
but only if you place those extensions in the same file.

What I am fighting for is an access specifier that allows us to extend types in 
another file, to avoid the gargantuan file syndrome that can easily ensue if 
you need many extensions to the type.

Don't forget, if it's visible to another file, it can be abused by the 
inexperienced working in the same module

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

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 powerful and 
few do they are actually used. Right now we have private and fileprivate and 
many people don't use them consistently because they are so similar. We need 
only one private access control and I'm voting for fileprivate because it is 
the one which is the simplest while still working well with Swift's extension 
mechanisms.

On 20 Feb 2017, at 12:38, Joanna Carter via swift-evolution 
 wrote:

>> 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 look at what the 
>> method does, so you might miss this fact since you didn't go and read the 
>> docs. Xcode wouldn't even offer you this method in autocompletion if it were 
>> marked protected.
>> 
>> I'm not saying that this is something the Swift community can't live 
>> without, but it's of a huge convenience for newcomers to a project for whom 
>> the IDE wouldn't offer methods that should not get called from outside of 
>> the enclosing type.
>> 
>> I believe we are running to a point where the community is divided into two 
>> major camps - one part that would like to get the access control almost 
>> eliminated as they don't the see it that much useful; and second part that 
>> on the other hand would very much like to see extended access control - not 
>> by files/modules, but by the enclosing type. People are unlikely to switch 
>> these camps as their view on the subject is mostly shaped by their previous 
>> experience with working on team projects. 
>> 
>> IMHO, those who have previously worked with other experienced and 
>> responsible developers are probably advocates of less access control; those 
>> who have previously worked will less experienced developers are most likely 
>> pushing forward a more extended access control model.
>> 
>> I've previously worked as a lead developer in a few start-up businesses 
>> where people came and went and it was unnecessary burden to point to them 
>> why they shouldn't do something that way, that they overlooked that the 
>> member should not be invoked out of the enclosing context because they 
>> didn't full read documentation for that method; when you do this with a 10th 
>> person for the 100th time, you start wondering if this is one of those 
>> things that the language should help with a little by providing means of 
>> preventing people of misusing/abusing certain parts of the API.
> 
> Charlie, you really have hit the nail fairly and squarely on the head! :-)
> 
> It is all very well and good for experienced developers to say that others 
> should read the documentation but, do you know what? After more than 25 years 
> as a developer (including for languages that didn't have an IDE with 
> autocompletion), I still rely heavily on autocompletion to help me through 
> the morass that most frameworks ressemble.
> 
> The time saved be being able to see, at a glance, in the code that you are 
> writing, what you can and cannot use, must run into years. Yes, I do look 
> some stuff up in the UIKit and Cocoa source files and the documentation but 
> that all takes time.
> 
> I have also worked as a lead developer, as well as a creator of frameworks 
> and, as you rightly said, it is the inexperienced (or just darned lazy) 
> developers who will not read anything other than that which autocompletion 
> offers.
> 
> I once gave a task to such a developer, who then took three days to work out 
> their own implementation of a small class hierarchy. When I pressed them to 
> allow me to integrate their code, I found that it was incompatible with the 
> rest of the system and was allocating memory in one file and deallocating it 
> in another!
> 
> It took me half an hour to rewrite the whole thing from scratch.
> 
> The companies I have worked with don't want to have to allocate expensive 
> resources like us to routine tasks. Autocompletion is an absolute godsend for 
> both the inexperienced and experienced. Without good access control, enforced 
> by autocompletion, reliable code takes longer to write and costs more.
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> 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 access 
to otherwise private members within the context of a file.

I am totally for the Swift concept of protocols, structs and extensions but, at 
present, it is not possible to control the visibility of anything in an 
extension or a struct other than to either place the extensions in the same 
file as the type being extended, or make the whole shooting match internal.

> I think that a general `protected` feature is not very compatible with 
> Swift's extension-based approach, but I could imagine a feature specifically 
> for overriding. For example, a class like UIViewController might declare:
> 
>   open(override) internal func viewDidAppear(_ animated: Bool) { … }
>   // Or maybe `open internal(call)`? That'd be more like `public 
> internal(set)`…
> 
> And then public subclasses could override `viewDidAppear(_:)`, and those 
> overrides could call `super.viewDidAppear(_:)`, but neither other methods in 
> the subclass nor code outside the subclass could call it.

The problem with 'protected' as a keyword is that it has too many connotations 
of its use elsewhere for classes only.

I believe what some of us are attempting to propose here is a more 'universal' 
keyword that conveys the intent of being able to extend access of otherwise 
private members to (but only to) an 'extending entity'. So :

1. for classes - in subclasses or extensions

2. for structs, enums, etc - in extensions

> Would that fulfill your needs, or are you really looking for type-based 
> access control?

I must admit to being fairly old-school when it comes to access control in 
preferring type-based access control. Mainly down to my experience with trying 
to keep inexperienced developers from abusing (privileged) stuff when working 
in the same module.

In previous posts, I have used the keyword 'extensible' to denote the 
visibility of a member that fulfils the two definitions I give above.

The benefit of 'extensible' is that it does away with both the perceived need 
for protected in classes and fileprivate to allow extensions to see otherwise 
private members of the type they are extending.

I will reiterate my feelings : fileprivate is a kludge. It only really serves 
to encourage megalithic files in order to get around the lack of something akin 
to "extensible'

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ross O'Brien via swift-evolution]

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 sometimes that means
putting a property in the type rather than the extension and that requires
fileprivate. That's not ideal, but if there were an idiomatically neater
way to declare a private property in the extension and have Swift recognise
that property as being part of the type but contextually linked only to
that protocol conformance then that would be good.

'Fileprivate' makes files equivalent to submodules, and this can lead to
undesirably long files. Possibly the dependence on filesystem structure
feels restrictive to some developers. It seems to me that in this four-tier
structure (public, internal, fileprivate, private) that a significant
number of developers think that's one, maybe two tiers too many (the system
should be simplified), and for others that's one, maybe two tiers too few
(fileprivate is doing too much, and a submodule tier would relieve that
pressure).

I think a submodule access level has been suggested a lot of times, but I
don't think anyone's formally proposed a possible syntax for it.

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 moment I think there are four ways -
have I missed any?

1) Submodules correspond directly to file directories (simple, but possibly
binds a project too closely to an operating system, inflexible for systems
like Git).
2) The submodule has an access control file which lists its member files
(as modules do)
3) Files opt-in to membership of a submodule (e.g. 'memberOf Submodule'
just below 'import Foundation')
4) Files 'friend' other files into their submodule, somehow.

Worth noting: the latter three of these suggestions don't implicitly
prevent a file from being a member of more than one submodule.

I don't have my own answer to this question yet, but I think discussion of
it will help decide whether submodules are a practical possibility. If they
are, perhaps there's justification for fileprivate; if not, perhaps
reverting to Swift 2's private is better.

Thanks,
Ross


On Mon, Feb 20, 2017 at 10:41 AM, Dimitri Racordon via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 Netbeans. Xcode is great, but I think we should not design Swift
> thinking it’s the norm to use it.
>
> I’d favourite any kind of syntax that is baked in the same file as the
> code.
>
> Thanks,
> Dimitri
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> 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 look at what the 
> method does, so you might miss this fact since you didn't go and read the 
> docs. Xcode wouldn't even offer you this method in autocompletion if it were 
> marked protected.
> 
> I'm not saying that this is something the Swift community can't live without, 
> but it's of a huge convenience for newcomers to a project for whom the IDE 
> wouldn't offer methods that should not get called from outside of the 
> enclosing type.
> 
> I believe we are running to a point where the community is divided into two 
> major camps - one part that would like to get the access control almost 
> eliminated as they don't the see it that much useful; and second part that on 
> the other hand would very much like to see extended access control - not by 
> files/modules, but by the enclosing type. People are unlikely to switch these 
> camps as their view on the subject is mostly shaped by their previous 
> experience with working on team projects. 
> 
> IMHO, those who have previously worked with other experienced and responsible 
> developers are probably advocates of less access control; those who have 
> previously worked will less experienced developers are most likely pushing 
> forward a more extended access control model.
> 
> I've previously worked as a lead developer in a few start-up businesses where 
> people came and went and it was unnecessary burden to point to them why they 
> shouldn't do something that way, that they overlooked that the member should 
> not be invoked out of the enclosing context because they didn't full read 
> documentation for that method; when you do this with a 10th person for the 
> 100th time, you start wondering if this is one of those things that the 
> language should help with a little by providing means of preventing people of 
> misusing/abusing certain parts of the API.

Charlie, you really have hit the nail fairly and squarely on the head! :-)

It is all very well and good for experienced developers to say that others 
should read the documentation but, do you know what? After more than 25 years 
as a developer (including for languages that didn't have an IDE with 
autocompletion), I still rely heavily on autocompletion to help me through the 
morass that most frameworks ressemble.

The time saved be being able to see, at a glance, in the code that you are 
writing, what you can and cannot use, must run into years. Yes, I do look some 
stuff up in the UIKit and Cocoa source files and the documentation but that all 
takes time.

I have also worked as a lead developer, as well as a creator of frameworks and, 
as you rightly said, it is the inexperienced (or just darned lazy) developers 
who will not read anything other than that which autocompletion offers.

I once gave a task to such a developer, who then took three days to work out 
their own implementation of a small class hierarchy. When I pressed them to 
allow me to integrate their code, I found that it was incompatible with the 
rest of the system and was allocating memory in one file and deallocating it in 
another!

It took me half an hour to rewrite the whole thing from scratch.

The companies I have worked with don't want to have to allocate expensive 
resources like us to routine tasks. Autocompletion is an absolute godsend for 
both the inexperienced and experienced. Without good access control, enforced 
by autocompletion, reliable code takes longer to write and costs more.

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dimitri Racordon via swift-evolution]

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 
Netbeans. Xcode is great, but I think we should not design Swift thinking it’s 
the norm to use it.

I’d favourite any kind of syntax that is baked in the same file as the code.

Thanks,
Dimitri
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Thanks for the suggestion, I will give it some thought and may others will do 
the same.

My issue with this topic is that I feel there is a lot of emotion but not yet a 
clear agreed best path forward. We should also think about design and 
implementation opportunity cost, what are we not addressing/focusing 
on/designing by focusing on arguing loudly about reverting a change set?

Sent from my iPhone

> On 20 Feb 2017, at 09:15, Rien  wrote:
> 
> 
> 
> 
> 
>> 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 worlds?
> 
> Everything is open inside the project unless marked private (in the swift 2 
> sense, i.e. fileprivate)
> 
> If a project/module exports a library, the same applies, unless there is a 
> “library access level control file”.
> 
> If a "library access level control file” is present, all external access 
> defaults to private unless disclosed in the “library access level control 
> file”.
> 
> With proper IDE support, creating a "library access level control file” would 
> require only minimal effort.
> 
> This would allow cleaner source code as you do not have to specify every 
> access level all the time, reduces cognitive load during programming and 
> debugging, fits nicely in the progressive disclosure strategy, creates a more 
> readable interface for API users etc etc.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
>> 
>> Seriously, that was always my issue with that blog post, assuming that the 
>> Objective-C way of dealing with this issue was something worth moving 
>> forward and not a path to massively improve upon or to avoid.
>> 
>> Sent from my iPhone
>> 
>>> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> 
 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 “friend”-like feature where types that 
 need access to implementation details due to higher coupling could be 
 bundled into the same file. Outside of a desire of a scoped ‘private’ 
 simply to match the behavior of certain other languages, private is used 
 to hide implementation details from other parts of a file, while file 
 private exposes them within the file. 
 
 There is a potential that file-private can lead to an explosion of 
 complexity due to a large amount of “friendly types” being bundled into 
 the same file. In that sense, ‘private’ was wrong because it was adding 
 complexity at the file level, when really a new access level would 
 possibly have been more productive to define at the at the 
 small-group-of-files level - either via a friend access level or 
 submodules. We still have the potential of unmanageable files due to 
 friend types, but any additional access levels to aid with this problem 
 would have to be weighed against a now significantly more complex access 
 model including file and scoped private. In that sense, the inclusion of 
 scoped private may indeed be harmful in that it increases the challenge of 
 much more useful access levels being added to the language.
>>> 
>>> This is the core of what I have been saying.  If we don’t address this need 
>>> of “friendly types” in a swift-y way, we will have to keep coming back to 
>>> the drawing board (either for “friend” or “protected” or “submodules”).  I 
>>> really like swift 2 private, but it did cause long files because all of the 
>>> extensions and friends had to be stuck in the same file. What we are really 
>>> missing is something that has the connotation similar to private, but 
>>> allows access where needed.
>>> 
>>> I agree with most of what was said in this blog post from the swift devs:
>>> https://developer.apple.com/swift/blog/?id=11
>>> 
>>> The main exception is that I disagree that ‘internal’ maps to the ObjC case 
>>> where a second header was used (it doesn’t, and that is what is causing all 
>>> of this trouble).  Because internal is the default, it feels much too easy 
>>> to accidentally use parts of a type which should only be used by 
>>> extensions/subclasses/friend types. Remember, in an app (as opposed to a 
>>> framework), internal is basically equivalent to public.  With the second 
>>> header, users of the contents of that header had to explicitly include it, 
>>> which meant there was no chance of accidental use.
>>> 
>>> What we need is something which maps to that second header case while still 
>>> keeping everything conceptually simpl

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

[Goffredo Marocchi via swift-evolution]

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  wrote:
> 
> 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 Marocchi  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) :/.
>> 
>> Seriously, that was always my issue with that blog post, assuming that the 
>> Objective-C way of dealing with this issue was something worth moving 
>> forward and not a path to massively improve upon or to avoid.
>> 
>> Sent from my iPhone
>> 
>>> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> 
 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 “friend”-like feature where types that 
 need access to implementation details due to higher coupling could be 
 bundled into the same file. Outside of a desire of a scoped ‘private’ 
 simply to match the behavior of certain other languages, private is used 
 to hide implementation details from other parts of a file, while file 
 private exposes them within the file. 
 
 There is a potential that file-private can lead to an explosion of 
 complexity due to a large amount of “friendly types” being bundled into 
 the same file. In that sense, ‘private’ was wrong because it was adding 
 complexity at the file level, when really a new access level would 
 possibly have been more productive to define at the at the 
 small-group-of-files level - either via a friend access level or 
 submodules. We still have the potential of unmanageable files due to 
 friend types, but any additional access levels to aid with this problem 
 would have to be weighed against a now significantly more complex access 
 model including file and scoped private. In that sense, the inclusion of 
 scoped private may indeed be harmful in that it increases the challenge of 
 much more useful access levels being added to the language.
>>> 
>>> This is the core of what I have been saying.  If we don’t address this need 
>>> of “friendly types” in a swift-y way, we will have to keep coming back to 
>>> the drawing board (either for “friend” or “protected” or “submodules”).  I 
>>> really like swift 2 private, but it did cause long files because all of the 
>>> extensions and friends had to be stuck in the same file. What we are really 
>>> missing is something that has the connotation similar to private, but 
>>> allows access where needed.
>>> 
>>> I agree with most of what was said in this blog post from the swift devs:
>>> https://developer.apple.com/swift/blog/?id=11
>>> 
>>> The main exception is that I disagree that ‘internal’ maps to the ObjC case 
>>> where a second header was used (it doesn’t, and that is what is causing all 
>>> of this trouble).  Because internal is the default, it feels much too easy 
>>> to accidentally use parts of a type which should only be used by 
>>> extensions/subclasses/friend types. Remember, in an app (as opposed to a 
>>> framework), internal is basically equivalent to public.  With the second 
>>> header, users of the contents of that header had to explicitly include it, 
>>> which meant there was no chance of accidental use.
>>> 
>>> What we need is something which maps to that second header case while still 
>>> keeping everything conceptually simple and swift-y.
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

> 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 worlds?

Everything is open inside the project unless marked private (in the swift 2 
sense, i.e. fileprivate)

If a project/module exports a library, the same applies, unless there is a 
“library access level control file”.

If a "library access level control file” is present, all external access 
defaults to private unless disclosed in the “library access level control file”.

With proper IDE support, creating a "library access level control file” would 
require only minimal effort.

This would allow cleaner source code as you do not have to specify every access 
level all the time, reduces cognitive load during programming and debugging, 
fits nicely in the progressive disclosure strategy, creates a more readable 
interface for API users etc etc.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl

> 
> Seriously, that was always my issue with that blog post, assuming that the 
> Objective-C way of dealing with this issue was something worth moving forward 
> and not a path to massively improve upon or to avoid.
> 
> Sent from my iPhone
> 
> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution 
>  wrote:
> 
>> 
>>> 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 “friend”-like feature where types that need 
>>> access to implementation details due to higher coupling could be bundled 
>>> into the same file. Outside of a desire of a scoped ‘private’ simply to 
>>> match the behavior of certain other languages, private is used to hide 
>>> implementation details from other parts of a file, while file private 
>>> exposes them within the file. 
>>> 
>>> There is a potential that file-private can lead to an explosion of 
>>> complexity due to a large amount of “friendly types” being bundled into the 
>>> same file. In that sense, ‘private’ was wrong because it was adding 
>>> complexity at the file level, when really a new access level would possibly 
>>> have been more productive to define at the at the small-group-of-files 
>>> level - either via a friend access level or submodules. We still have the 
>>> potential of unmanageable files due to friend types, but any additional 
>>> access levels to aid with this problem would have to be weighed against a 
>>> now significantly more complex access model including file and scoped 
>>> private. In that sense, the inclusion of scoped private may indeed be 
>>> harmful in that it increases the challenge of much more useful access 
>>> levels being added to the language.
>> 
>> This is the core of what I have been saying.  If we don’t address this need 
>> of “friendly types” in a swift-y way, we will have to keep coming back to 
>> the drawing board (either for “friend” or “protected” or “submodules”).  I 
>> really like swift 2 private, but it did cause long files because all of the 
>> extensions and friends had to be stuck in the same file. What we are really 
>> missing is something that has the connotation similar to private, but allows 
>> access where needed.
>> 
>> I agree with most of what was said in this blog post from the swift devs:
>> https://developer.apple.com/swift/blog/?id=11
>> 
>> The main exception is that I disagree that ‘internal’ maps to the ObjC case 
>> where a second header was used (it doesn’t, and that is what is causing all 
>> of this trouble).  Because internal is the default, it feels much too easy 
>> to accidentally use parts of a type which should only be used by 
>> extensions/subclasses/friend types. Remember, in an app (as opposed to a 
>> framework), internal is basically equivalent to public.  With the second 
>> header, users of the contents of that header had to explicitly include it, 
>> which meant there was no chance of accidental use.
>> 
>> What we need is something which maps to that second header case while still 
>> keeping everything conceptually simple and swift-y.
>> 
>> Thanks,
>> Jon
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

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 Marocchi  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) :/.
> 
> Seriously, that was always my issue with that blog post, assuming that the 
> Objective-C way of dealing with this issue was something worth moving forward 
> and not a path to massively improve upon or to avoid.
> 
> Sent from my iPhone
> 
> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 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 “friend”-like feature where types that need 
>>> access to implementation details due to higher coupling could be bundled 
>>> into the same file. Outside of a desire of a scoped ‘private’ simply to 
>>> match the behavior of certain other languages, private is used to hide 
>>> implementation details from other parts of a file, while file private 
>>> exposes them within the file. 
>>> 
>>> There is a potential that file-private can lead to an explosion of 
>>> complexity due to a large amount of “friendly types” being bundled into the 
>>> same file. In that sense, ‘private’ was wrong because it was adding 
>>> complexity at the file level, when really a new access level would possibly 
>>> have been more productive to define at the at the small-group-of-files 
>>> level - either via a friend access level or submodules. We still have the 
>>> potential of unmanageable files due to friend types, but any additional 
>>> access levels to aid with this problem would have to be weighed against a 
>>> now significantly more complex access model including file and scoped 
>>> private. In that sense, the inclusion of scoped private may indeed be 
>>> harmful in that it increases the challenge of much more useful access 
>>> levels being added to the language.
>> 
>> This is the core of what I have been saying.  If we don’t address this need 
>> of “friendly types” in a swift-y way, we will have to keep coming back to 
>> the drawing board (either for “friend” or “protected” or “submodules”).  I 
>> really like swift 2 private, but it did cause long files because all of the 
>> extensions and friends had to be stuck in the same file. What we are really 
>> missing is something that has the connotation similar to private, but allows 
>> access where needed.
>> 
>> I agree with most of what was said in this blog post from the swift devs:
>> https://developer.apple.com/swift/blog/?id=11 
>> 
>> 
>> The main exception is that I disagree that ‘internal’ maps to the ObjC case 
>> where a second header was used (it doesn’t, and that is what is causing all 
>> of this trouble).  Because internal is the default, it feels much too easy 
>> to accidentally use parts of a type which should only be used by 
>> extensions/subclasses/friend types. Remember, in an app (as opposed to a 
>> framework), internal is basically equivalent to public.  With the second 
>> header, users of the contents of that header had to explicitly include it, 
>> which meant there was no chance of accidental use.
>> 
>> What we need is something which maps to that second header case while still 
>> keeping everything conceptually simple and swift-y.
>> 
>> Thanks,
>> Jon
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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 moving forward 
and not a path to massively improve upon or to avoid.

Sent from my iPhone

> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution 
>  wrote:
> 
> 
>> 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 “friend”-like feature where types that need 
>> access to implementation details due to higher coupling could be bundled 
>> into the same file. Outside of a desire of a scoped ‘private’ simply to 
>> match the behavior of certain other languages, private is used to hide 
>> implementation details from other parts of a file, while file private 
>> exposes them within the file. 
>> 
>> There is a potential that file-private can lead to an explosion of 
>> complexity due to a large amount of “friendly types” being bundled into the 
>> same file. In that sense, ‘private’ was wrong because it was adding 
>> complexity at the file level, when really a new access level would possibly 
>> have been more productive to define at the at the small-group-of-files level 
>> - either via a friend access level or submodules. We still have the 
>> potential of unmanageable files due to friend types, but any additional 
>> access levels to aid with this problem would have to be weighed against a 
>> now significantly more complex access model including file and scoped 
>> private. In that sense, the inclusion of scoped private may indeed be 
>> harmful in that it increases the challenge of much more useful access levels 
>> being added to the language.
> 
> This is the core of what I have been saying.  If we don’t address this need 
> of “friendly types” in a swift-y way, we will have to keep coming back to the 
> drawing board (either for “friend” or “protected” or “submodules”).  I really 
> like swift 2 private, but it did cause long files because all of the 
> extensions and friends had to be stuck in the same file. What we are really 
> missing is something that has the connotation similar to private, but allows 
> access where needed.
> 
> I agree with most of what was said in this blog post from the swift devs:
> https://developer.apple.com/swift/blog/?id=11
> 
> The main exception is that I disagree that ‘internal’ maps to the ObjC case 
> where a second header was used (it doesn’t, and that is what is causing all 
> of this trouble).  Because internal is the default, it feels much too easy to 
> accidentally use parts of a type which should only be used by 
> extensions/subclasses/friend types. Remember, in an app (as opposed to a 
> framework), internal is basically equivalent to public.  With the second 
> header, users of the contents of that header had to explicitly include it, 
> which meant there was no chance of accidental use.
> 
> What we need is something which maps to that second header case while still 
> keeping everything conceptually simple and swift-y.
> 
> Thanks,
> Jon
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

> 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 “friend”-like feature where types that need 
> access to implementation details due to higher coupling could be bundled into 
> the same file. Outside of a desire of a scoped ‘private’ simply to match the 
> behavior of certain other languages, private is used to hide implementation 
> details from other parts of a file, while file private exposes them within 
> the file. 
> 
> There is a potential that file-private can lead to an explosion of complexity 
> due to a large amount of “friendly types” being bundled into the same file. 
> In that sense, ‘private’ was wrong because it was adding complexity at the 
> file level, when really a new access level would possibly have been more 
> productive to define at the at the small-group-of-files level - either via a 
> friend access level or submodules. We still have the potential of 
> unmanageable files due to friend types, but any additional access levels to 
> aid with this problem would have to be weighed against a now significantly 
> more complex access model including file and scoped private. In that sense, 
> the inclusion of scoped private may indeed be harmful in that it increases 
> the challenge of much more useful access levels being added to the language.

This is the core of what I have been saying.  If we don’t address this need of 
“friendly types” in a swift-y way, we will have to keep coming back to the 
drawing board (either for “friend” or “protected” or “submodules”).  I really 
like swift 2 private, but it did cause long files because all of the extensions 
and friends had to be stuck in the same file. What we are really missing is 
something that has the connotation similar to private, but allows access where 
needed.

I agree with most of what was said in this blog post from the swift devs:
https://developer.apple.com/swift/blog/?id=11

The main exception is that I disagree that ‘internal’ maps to the ObjC case 
where a second header was used (it doesn’t, and that is what is causing all of 
this trouble).  Because internal is the default, it feels much too easy to 
accidentally use parts of a type which should only be used by 
extensions/subclasses/friend types. Remember, in an app (as opposed to a 
framework), internal is basically equivalent to public.  With the second 
header, users of the contents of that header had to explicitly include it, 
which meant there was no chance of accidental use.

What we need is something which maps to that second header case while still 
keeping everything conceptually simple and swift-y.

Thanks,
Jon


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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 access controls 
and goes beyond the current "let's just kill fileprivate and make private 
behave like it".

The current private provides useful functionality for a way of composing and 
designing objects... fileprivate is four more characters and most of us use 
autocompletion features on modern IDE's now, does what it says on the tin, 
provides no issue to newcomers really, and it is not clear to me we have a 
better alternative... we all adopted this current approach for a reason, the 
core team did not trip into it.


Also, do we have data about this being an issue? For an opinionated language 
and opinionated audience, this is a bit OT and we should discuss it in a 
different thread, we should be gathering data and help it drive our opinions 
(to back claims about better stability, higher performance, etc...).

Sent from my iPhone

> On 19 Feb 2017, at 23:52, 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 provide those examples? This thread has been actively discussed for 
> close to a week now, so it would be good to do something concrete about it. I 
> think Chris’ second suggestion fits my idea of a reasonable “Default” level 
> of privacy when starting out, and fits the model of progressive disclosure as 
> you so excellently pointed out.
> 
> Is this something that should go through a proper Proposal? Is someone doing 
> this already? I’d like to help/contribute if it is.
> 
> thanks,
> 
> 
> Tony
> 
> 
> 
> --
> Tony Arnold
> +61 411 268 532
> http://thecocoabots.com/
> 
> ABN: 14831833541
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 19, 2017, at 10:31 PM, David Hart  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 
>>>  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 about 
>> it. I think Chris’ second suggestion fits my idea of a reasonable “Default” 
>> level of privacy when starting out, and fits the model of progressive 
>> disclosure as you so excellently pointed out.
>> 
>> Is this something that should go through a proper Proposal? Is someone doing 
>> this already? I’d like to help/contribute if it is.
> 
> Chris' second suggestion was dropped by Chris himself after we discussed the 
> disadvantages it adds. I am already working on a proposal to revert to Swift 
> 2's private and it should be ready soon. 

I think this is a good strategy, the alternatives should include keeping scope 
private but with a different name. Focus on specific code examples and specify 
how having two overlapping specifiers is harmful.   This is how we were able to 
reverse only being able to use if let instead of if var 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008145.html



>> thanks,
>> 
>> 
>> Tony
>> 
>> 
>> 
>> --
>> Tony Arnold
>> +61 411 268 532
>> http://thecocoabots.com/
>> 
>> ABN: 14831833541
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> 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 
>>  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 about it. I 
> think Chris’ second suggestion fits my idea of a reasonable “Default” level 
> of privacy when starting out, and fits the model of progressive disclosure as 
> you so excellently pointed out.
> 
> Is this something that should go through a proper Proposal? Is someone doing 
> this already? I’d like to help/contribute if it is.

Chris' second suggestion was dropped by Chris himself after we discussed the 
disadvantages it adds. I am already working on a proposal to revert to Swift 
2's private and it should be ready soon. 

> thanks,
> 
> 
> Tony
> 
> 
> 
> --
> Tony Arnold
> +61 411 268 532
> http://thecocoabots.com/
> 
> ABN: 14831833541
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> 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. If you 
> want other modules to see features of your module, you make them public. If 
> something is an implementation detail that even other parts of your module 
> shouldn’t mess with, you make them private”
> 
> I think I would have trouble *just* describing private vs file private in 
> that amount of space. One sign of the complexity was that even after a 
> ridiculous amount of bike shedding, we couldn’t come up with better way to 
> distinguish the two than to call one “fileprivate”. So I would say for the 
> purposes of swift as a language suitable for learning, the change was 
> harmful. 

Swift’s scope private is not different than other languages. 

> 
> Secondly, there are reasons to choose one versus the other, but the 
> combination of the meaning of the keyword changing between swift 2 and 3 and 
> the spelling of “fileprivate” means that the choice of one or the other 
> doesn’t really communicate anything to a developer of a typical project - it 
> appears to often be a matter of the legacy of the code as well as developer 
> taste. That the choice between private and file private doesn’t illustrate 
> intent is harmful to coordination.

This really depends on where private is. If it on the top scope then private is 
the same as file-private and your statement is correct. 

SE-0025 was changed to allow higher access modifier for inner types and this is 
when things started to get confusing because the vast majority of times when 
scope private was being used in reality is the same as fileprivate. The fact 
that we encourage the use of scope private over file-private is harmful because 
of the confusion. 


// File.swift

private let myString = ""   // fileprivate same as private
fileprivate let myString2 = ""  // fileprivate same as private


private struct MyType {  // fileprivate same as private
fileprivate struct MyInnerType{  // private never the same as private
fileprivate struct MyInnerType{} // private never the same as private
}
}

// end of File.swift



 
> 
> 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 “friend”-like feature where types that need 
> access to implementation details due to higher coupling could be bundled into 
> the same file. Outside of a desire of a scoped ‘private’ simply to match the 
> behavior of certain other languages, private is used to hide implementation 
> details from other parts of a file, while file private exposes them within 
> the file. 
> 
> There is a potential that file-private can lead to an explosion of complexity 
> due to a large amount of “friendly types” being bundled into the same file. 
> In that sense, ‘private’ was wrong because it was adding complexity at the 
> file level, when really a new access level would possibly have been more 
> productive to define at the at the small-group-of-files level - either via a 
> friend access level or submodules. We still have the potential of 
> unmanageable files due to friend types, but any additional access levels to 
> aid with this problem would have to be weighed against a now significantly 
> more complex access model including file and scoped private. In that sense, 
> the inclusion of scoped private may indeed be harmful in that it increases 
> the challenge of much more useful access levels being added to the language.
> 
> -DW
> 
>> On Feb 18, 2017, at 11:57 PM, Jose Cheyo Jimenez via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 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, exist.
>>> 
>>> Zachary
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

__

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

[David Waite via swift-evolution]

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 
something is an implementation detail that even other parts of your module 
shouldn’t mess with, you make them private”

I think I would have trouble *just* describing private vs file private in that 
amount of space. One sign of the complexity was that even after a ridiculous 
amount of bike shedding, we couldn’t come up with better way to distinguish the 
two than to call one “fileprivate”. So I would say for the purposes of swift as 
a language suitable for learning, the change was harmful. 

Secondly, there are reasons to choose one versus the other, but the combination 
of the meaning of the keyword changing between swift 2 and 3 and the spelling 
of “fileprivate” means that the choice of one or the other doesn’t really 
communicate anything to a developer of a typical project - it appears to often 
be a matter of the legacy of the code as well as developer taste. That the 
choice between private and file private doesn’t illustrate intent is harmful to 
coordination.

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 “friend”-like feature where types that need 
access to implementation details due to higher coupling could be bundled into 
the same file. Outside of a desire of a scoped ‘private’ simply to match the 
behavior of certain other languages, private is used to hide implementation 
details from other parts of a file, while file private exposes them within the 
file. 

There is a potential that file-private can lead to an explosion of complexity 
due to a large amount of “friendly types” being bundled into the same file. In 
that sense, ‘private’ was wrong because it was adding complexity at the file 
level, when really a new access level would possibly have been more productive 
to define at the at the small-group-of-files level - either via a friend access 
level or submodules. We still have the potential of unmanageable files due to 
friend types, but any additional access levels to aid with this problem would 
have to be weighed against a now significantly more complex access model 
including file and scoped private. In that sense, the inclusion of scoped 
private may indeed be harmful in that it increases the challenge of much more 
useful access levels being added to the language.

-DW

> On Feb 18, 2017, at 11:57 PM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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, exist.
>> 
>> Zachary
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

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 provide those examples? This thread has been actively discussed for 
> close to a week now, so it would be good to do something concrete about it. I 
> think Chris’ second suggestion fits my idea of a reasonable “Default” level 
> of privacy when starting out, and fits the model of progressive disclosure as 
> you so excellently pointed out.
> 
> Is this something that should go through a proper Proposal? Is someone doing 
> this already? I’d like to help/contribute if it is.

I will write a proposal to address this problem.

> 
> thanks,
> 
> 
> Tony
> 
> 
> 
> --
> Tony Arnold
> +61 411 268 532
> http://thecocoabots.com/
> 
> ABN: 14831833541
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Arnold via swift-evolution]

> 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 about it. I 
think Chris’ second suggestion fits my idea of a reasonable “Default” level of 
privacy when starting out, and fits the model of progressive disclosure as you 
so excellently pointed out.

Is this something that should go through a proper Proposal? Is someone doing 
this already? I’d like to help/contribute if it is.

thanks,


Tony



--
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> 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 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 conventions of 
>> other languages. It's useful sometimes. But in this case it goes directly 
>> against the philosophy of Swift's extension feature. Swift should be allowed 
>> to go against the norm when it serves the languages. And in this case, if 
>> only one private should exist, it's the file-s open one.
> 
> Yes, I think making private not work well with extensions was the "actively 
> harmful" aspect of SE-0025.  Scoped access itself is not actively harmful and 
> should not be removed, but it could be renamed so that private works the way 
> people want it to again.
> 
I think this an excellent point. In your proposal you can also mention that 
perhaps the renaming on private to mean scope private was premature since the 
primary goal was to match other languages notion on private. The issue is that 
Swift's public does not match other languages public. Should we then also 
change Swift's public to mean the established meaning of public in other 
languages? By no means! Swift is different. We agree that scope private is 
useful to some people by we believe that it is the wrong default for Swift. It 
is actively harmful in that by making it the default it forces a programmer to 
think fileprivate the moment the want to extend a type and access their private 
members. This in turn forces every programmer to have to deal with two access 
modifiers before they even make anything public. We believe this goes against 
the swift  centric feature of extensibility via extensions and the philosophy 
of "the complexity inherited in the language needs to be progressively 
disclosed". In the same way that public doesn't make classes open, private 
should not be scope private. 

This will make it possible for people to lock down in steps instead of all 
together which doesn't work with extensions.  

We need more examples to make this case. 



>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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 does 
not make POP better in and of itself (seriously now, this is what will trip 
people up when learning Swift and not default methods and static vs dynamic 
dispatching or implementing copy on write for custom value types using 
reference types inside for backing storage?) and does not help people write 
classes better...

Sent from my iPhone

> On 19 Feb 2017, at 17:14, David Hart  wrote:
> 
> 
>> 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 value types ;)..
> 
> But if both exist, we are keeping two access levels that are quite similar to 
> please two groups of people: people that are used to scoped-access from other 
> languages and people who prefer an access level which works better with 
> Swift’s idioms. It’s wasteful to keep two around IMHO.
> 
>> Sent from my iPhone
>> 
>>> On 19 Feb 2017, at 13:55, David Hart  wrote:
>>> 
>>> 
>>> 
 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 conventions of 
>>> other languages. It's useful sometimes. But in this case it goes directly 
>>> against the philosophy of Swift's extension feature. Swift should be 
>>> allowed to go against the norm when it serves the languages. And in this 
>>> case, if only one private should exist, it's the file-s open one.
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> 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 value types ;)..

But if both exist, we are keeping two access levels that are quite similar to 
please two groups of people: people that are used to scoped-access from other 
languages and people who prefer an access level which works better with Swift’s 
idioms. It’s wasteful to keep two around IMHO.

> Sent from my iPhone
> 
>> On 19 Feb 2017, at 13:55, David Hart  wrote:
>> 
>> 
>> 
>>> 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 conventions of 
>> other languages. It's useful sometimes. But in this case it goes directly 
>> against the philosophy of Swift's extension feature. Swift should be allowed 
>> to go against the norm when it serves the languages. And in this case, if 
>> only one private should exist, it's the file-s open one.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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  wrote:
> 
> 
> 
>> 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 conventions of 
> other languages. It's useful sometimes. But in this case it goes directly 
> against the philosophy of Swift's extension feature. Swift should be allowed 
> to go against the norm when it serves the languages. And in this case, if 
> only one private should exist, it's the file-s open one.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

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 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 conventions of 
> other languages. It's useful sometimes. But in this case it goes directly 
> against the philosophy of Swift's extension feature. Swift should be allowed 
> to go against the norm when it serves the languages. And in this case, if 
> only one private should exist, it's the file-s open one.

Yes, I think making private not work well with extensions was the "actively 
harmful" aspect of SE-0025.  Scoped access itself is not actively harmful and 
should not be removed, but it could be renamed so that private works the way 
people want it to again.

> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> 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 conventions of 
other languages. It's useful sometimes. But in this case it goes directly 
against the philosophy of Swift's extension feature. Swift should be allowed to 
go against the norm when it serves the languages. And in this case, if only one 
private should exist, it's the file-s open one.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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 you use the 
class type to reference the created instance).

The current private is closer to other languages than the previous one we had 
which now has in fileprivate a better name.

Sent from my iPhone

> On 19 Feb 2017, at 08:12, Rien via swift-evolution 
>  wrote:
> 
> 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 ones. Learning swift, increased cognitive load during programming, 
> mistakes to be corrected, difficulty in testing, and I am sure many more can 
> be found.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 19 Feb 2017, at 07:57, Jose Cheyo Jimenez via swift-evolution 
>>  wrote:
>> 
>> 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 
>>> 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, exist.
>>> 
>>> Zachary
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

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 
ones. Learning swift, increased cognitive load during programming, mistakes to 
be corrected, difficulty in testing, and I am sure many more can be found.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 19 Feb 2017, at 07:57, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 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 
>> 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, exist.
>> 
>> Zachary
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

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 
> 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, exist.
> 
> Zachary
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Waldowski via swift-evolution]

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, exist.


Zachary


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matt Whiteside via swift-evolution]

> 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 complications that 
> only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Slava

I am behind this idea too.  The access control modifiers seem like mostly a 
distraction from more interesting considerations.  If they are causing big 
headaches in the implementation, I wouldn’t mind if they were cut down to just 
internal and public.

-Matt


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> 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 
>> mailto: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 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 of tackling that issue, these are suggestions to
>> invent ad-hoc units of code (scope + extensions only in the same file,
>> scope + extensions only in the same module, class + extensions only in the
>> same file + subclasses only in the same module), and it is possible to
>> invent arbitrary many of these.
>> 
>> 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 email in this thread. with current 'private' he 
>> can *guarantee* that no code touches internal props even in the same file), 
>> also many of us need a way to share some details only for 
>> extensions/subtypes in other files in the same module/submodule even just to 
>> organize code as *one* need/want and to express intention about who should 
>> "touch" this code and get help from compiler when accidentally try to use 
>> protected method/prop.
>> 
>> I reject the premise that it is a goal of the Swift compiler to protect you 
>> from yourself.
>> 
>> I should clarify, it should certainly protect you from unintentional 
>> accidents that you make, where those are foreseeable, etc. But here we're 
>> talking about _you_ invoking functions that _you_ wrote, which is a pretty 
>> darn clear demonstration of intentionality. And so what I mean to say is 
>> that the Swift compiler, IMO, has no real business trying to protect your 
>> intentions from your other intentions.
> 
> With all due respect (and I do respect you as a person with quite an 
> insight), why does Swift then (by default) check for (U)Int overflows, 
> against nil values, etc, etc. These are all things that are quite protecting 
> you from yourself. In a perfect world, you code your stuff in a way where you 
> don't need these checks as you'd write code that would handle these 
> scenarios. Oh wait, that's Objective-C...
> 
> Overflow, nil values, etc., all go to Swift's promising of memory safety by 
> default. They also reflect errors of omission: we unintentionally forget to 
> handle these cases. 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 own intentional 
> acts.

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 look at what the 
method does, so you might miss this fact since you didn't go and read the docs. 
Xcode wouldn't even offer you this method in autocompletion if it were marked 
protected.

I'm not saying that this is something the Swift community can't live without, 
but it's of a huge convenience for newcomers to a project for whom the IDE 
wouldn't offer methods that should not get called from outside of the enclosing 
type.

I believe we are running to a point where the community is divided into two 
major camps - one part that would like to get the access control almost 
eliminated as they don't the see it that much useful; and second part that on 
the other hand would very much like to see extended access control - not by 
files/modules, but by the enclosing type. People are unlikely to switch these 
camps as their view on the subject is mostly shaped by their previous 
experience with working on team projects. 

IMHO, those who have previously worked with other experienced and responsible 
developers are probably advocates of less access control; those who have 
previously worked will less experienced developers are most likely pushing 
forward a more extended access control model.

I've previously worked as a lead developer in a few start-up businesses where 
people came and went and it was unnecessary burden to point to them why they 
shouldn't do something that way, that they overlooked that the member should 
not be invoked out of the enclosing context because they didn't full read 
documentation for that method; when you do this with a 10th person for the 
100th time, you start w

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

[David Rönnqvist via swift-evolution]

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 "Slot" enum values is able to inspect 
fileprivate information about each Slot to expose some external higher level 
functionality on the Slots struct. 

A CollectionObserver class which inherits from an Observer class (same file) 
and is able to inspect and modify detailed fileprivate state. 


So, while #2 would work for me most of the time, I like the ability to put 
related types in the same file and have them expose more functionality to each 
other than they do to the rest of the project. Sort of like a micro (2-3 type) 
submodule.

In the end I find #1 simpler and more flexible.

Regards,
David

> On 15 Feb 2017, at 10:34, 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 future refinement of extensions to this model:
> 
> a) 1st party extension (extension defined and owned by the type owner): 
> extension is defined in the same module as the base type:
> 
> - allows access to private type properties and functions even if the base 
> type and extension are in different files
> - allows the definition of stored properties for value and class types
> 
> b) 3rd party extension (extension is defined and owned by the _user_ of a 
> type): extension is defined in a parent module and the base type is defined 
> in a sub-module:
> 
> - forbids access to private properties and functions from the imported type
> - forbids the definition of stored properties for value types
> - MAY allow the definition of stored properties on class types (haven’t 
> really convinced myself that this would be a good idea)
> 
> “parent module” would either mean the application that links against a module 
> (what is supported today) but also the parent module of a sub-module 
> (potential future addition).
> 
> 
> Regards,
> 
> Dietmar Planitzer
> 
> 
>> On Feb 14, 2017, at 21:31, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 14, 2017, at 3:20 AM, David Hart  wrote:
>>> 
>>> 
 On 14 Feb 2017, at 09:25, Goffredo Marocchi  wrote:
 
 I disagree with that as well as I still think we are damaging the language 
 each time we take a known concept (like access levels) and give new 
 meanings to the same keywords. I still look baffled at the redefinition of 
 do and the addition of repeat for example...
 
 Private, the way it was before, was an admittedly curious take on how most 
 languages mean by private and we have jumped through a lot of hoops to 
 justify why we did not start with Java/C++/C# like access control and 
 augmented it instead of redefining things, omitting others, and then 
 constantly pulling the language left and right with not a lot of permanent 
 consensus either way as this discussion and others before show.
>>> 
>>> It's a curious take, but it is a curious take is perfectly coherent with 
>>> Swift extensions. How else would you access private implementation details 
>>> from an extension? But putting it in the same file, instead of having to 
>>> resort to an internal access level.
>> 
>> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
>> intentionally designed to remain familiar (and thus reuses many keywords 
>> across the language family), it often does so with slightly different 
>> meaning / behavior.  Consider ‘throw’ for example.
>> 
>> Keeping with the spirit of Swift and staying consistent with its design, I 
>> see two plausible meanings for private:
>> 
>> Private could mean either:
>> 1) private to the file (Swift 2 semantics)
>> 2) accessible only to the current type/scope and to extensions to that type 
>> that are in the current file.
>> 
>> I don’t think we’ve ever evaluated and debated approach #2 systematically.
>> 
>> -Chris
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 be overridden by subclasses but, most 
> definitely, not callable from any code outside of that hierarchy. For that, I 
> express that intent by declaring such stuff as protected, thus preventing 
> "unauthorised" use from outside the intended hierarchy.

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?

I think that a general `protected` feature is not very compatible with Swift's 
extension-based approach, but I could imagine a feature specifically for 
overriding. For example, a class like UIViewController might declare:

open(override) internal func viewDidAppear(_ animated: Bool) { … }
// Or maybe `open internal(call)`? That'd be more like `public 
internal(set)`…

And then public subclasses could override `viewDidAppear(_:)`, and those 
overrides could call `super.viewDidAppear(_:)`, but neither other methods in 
the subclass nor code outside the subclass could call it.

Would that fulfill your needs, or are you really looking for type-based access 
control?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> 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 only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.

Removal of private in any form would prove problematic for situations where you 
have a "lazy" var that needs to be "reset" e.g.


  var dataScope: DataScope = .all
  {
didSet
{
  if dataScope != oldValue
  {
_fetchedResultsController = nil
  }
}
  }
  
  private var _fetchedResultsController: NSFetchedResultsController?
  
  fileprivate var fetchedResultsController: NSFetchedResultsController?
  {
get
{
  if _fetchedResultsController == nil
  {
// some stuff

if case .filtered(let filter) = self.dataScope
{
  let predicate = NSPredicate(format: "artist.imageName contains[cd] 
%@", filter)
  
  request.predicate = predicate
}

self._fetchedResultsController = 
NSFetchedResultsController(fetchRequest: request,
   
managedObjectContext: DataProvider.sharedInstance.managedObjectContext,
   
sectionNameKeyPath: "day.narrative",
   cacheName: nil)
  }
  
  return _fetchedResultsController
}
  }


This code is used in a public class which is used to provide the dataSource for 
a UITableView, therefore, the only members that should be exposed are the 
relevant methods for fetching data for the cells in the tableView, which are 
declared in a small extension in the same file. Which is why 
fetchedResultsController is fileprivate for access in the extension and 
_fetchedResultsController is private to ensure neither I, nor anyone who takes 
over the code, can call the underscored version, thus failing to lazily 
initialise the var.

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

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 properties in private as we don't support stored properties in 
extensions. And, without it, I think private is overly hamstrung when defining 
classes and types with extensions. There is no difference to the compilation 
beyond a rule that the compiler enforces, but can optimise anyway. In which 
case, it is purely communicative, and is therefore practically useless because 
I can't declare the property the method uses in that extension anyway. And 
littering my code with the ugly fileprivate marker is just an annoying 
inconvenience.

+1 also to add in something like 'protected'. It's a hole in the language where 
subclasses may have reasons to access but other types have no business touching.

> On 18 Feb 2017, at 2:38 pm, Jonathan Hull via swift-evolution 
>  wrote:
> 
> 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.  It also neatly avoids the issues mentioned in 
> the blog post.
> 
> Thanks,
> Jon
> 
>> On Feb 16, 2017, at 10:47 PM, Jose Cheyo Jimenez via swift-evolution 
>>  wrote:
>> 
>> 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 annotation for those 
>>> who want a more fine-grained solution:
>>> 
>>> @protected private - members accessable only from the class/struct/enum/... 
>>> and their extensions within the file
>>> 
>>> @protected internal - again, but you can access it even from extensions and 
>>> subclasses outside of the file within the entire module.
>>> 
>>> @protected public/open - the same as above, but outside the modules.
>>> 
>>> To me, this way most people here will be happy:
>>> 
>>> - those wishing the access control gets simplified - it in fact does, you 
>>> don't need to use @protected, if you don't want to/need to.
>>> - those who need a fine-grained solution, here it is.
>>> 
>>> 
>>> 
 On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
  wrote:
 
 
 
 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. 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 only. No 
>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Eh, I've used `private` to keep myself honest in terms of going through 
> some book-keeping functions instead of directly accessing a property.
 
 This is exactly the kind of thing I like it for and why I hope we might be 
 able to keep scoped access even if it gets a new name that ends up as 
 awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
 
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

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.  It also neatly avoids the issues mentioned in the blog post.

Thanks,
Jon

> On Feb 16, 2017, at 10:47 PM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> https://developer.apple.com/swift/blog/?id=11 
> 
> 
> 
> 
> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 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 the file
>> 
>> @protected internal - again, but you can access it even from extensions and 
>> subclasses outside of the file within the entire module.
>> 
>> @protected public/open - the same as above, but outside the modules.
>> 
>> To me, this way most people here will be happy:
>> 
>> - those wishing the access control gets simplified - it in fact does, you 
>> don't need to use @protected, if you don't want to/need to.
>> - those who need a fine-grained solution, here it is.
>> 
>> 
>> 
>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
> mailto:swift-evolution@swift.org>> 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 complications 
> that only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
 
 Eh, I've used `private` to keep myself honest in terms of going through 
 some book-keeping functions instead of directly accessing a property.
>>> 
>>> This is exactly the kind of thing I like it for and why I hope we might be 
>>> able to keep scoped access even if it gets a new name that ends up as 
>>> awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
>>> 
 
 - Dave Sweeris
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> 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 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 path for existing code.
>> 
>> 
>> I don’t think there is evidence that scope private in Swift3 is "actively 
>> harmful”. 
>> Reverting to Swift2 file-private as private is not clearly better. 
>> The community has not converged on a clear winner. 
>> 
>> The only positive thing here is that if we get rid of scope private then it 
>> will be easy to make private alias to file-private so no code will break, 
>> but we would be removing a feature so I would think this is a breaking 
>> change. 
>> 
>> Would removing private and fileprivate by making them alias to internal also 
>> be a breaking change? Even if the code will still compile?
> 
> Thanks for posting this Jose.  I think the point that has near unanimous 
> agreement is that assigning `private` the meaning of scoped access was a 
> mistake.  `fileprivate` is too awkward given how frequently it is necessary 
> in common idioms of Swift code organization.  
> 
> Whether scoped access itself is a valuable feature and whether it should 
> remain is the question that is turning out to be very controversial.  The 
> mistake we made with the keywords in Swift 3 certainly didn't help make the 
> case for it.  
> 
> That's why I would like to see us try to fix that mistake.  I think everyone 
> can be reasonably happy if we can all use `private` the way we did in Swift 2 
> and `scoped` can become a style issue.  Some teams can have a linter reject 
> it and those of us who like it can continue using it.  As a bonus, we would 
> eliminate an awkward keyword.

I appreciate the enthusiasm about this but the same argument can be used the 
other way. 

What about renaming `fileprivate` to `privy`. Shorter than private, typing 
`pri` would auto complete to it,  more swifty. Win Win. :) 

Its going to be hard finding names for either scope private or file private 
that the community will agree with. 

Its going to be a hard sale given the other more important features being 
worked on.

> 
>> 
>> This is a linter problem. If people don’t want other people in their team to 
>> use scope private then make it part of the coding style. 
>> 
>> If people do not want fileprivate because it looks ugly, then force 
>> everybody to use scope private using a linter like swiftlint. 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
> mailto:swift-evolution@swift.org>> 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 module definitely benefit from 
> access control and being able to consume a clearly-defined interface.
 
 I think failing to provide some sort of below-`internal` privacy would be 
 missing *really* low-hanging fruit for no good reason. The languages I can 
 think of which don't include some sort of sub-library-wide privacy 
 level—Objective-C, Javascript, Perl, Python—usually have very simple 
 object designs with a flat namespace. (Well, there's Rust, but Rust lets 
 you wrap anything you'd like in a module.) Even Objective-C in practice 
 includes a `fileprivate` equivalent in the form of methods declared only 
 in the .m file.
 
 I also think it's often helpful to be able to change a member's access 
 level without having to change all references to it. Publishing or 
 privatizing an interface is not an uncommon refactoring.
 
 Not everybody likes our current semantics, but that's no reason to throw 
 the feature out entirely.
>>> 
>>> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
>>> we can reconsider using `scoped` as the keyword for scoped access rather 
>>> than abandoning it.  Does anyone remember why this was considered a bad 
>>> idea?
>>> 
 
 -- 
 Brent Royal-Gordon
 Architechies
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 

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

[Matthew Johnson via swift-evolution]

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 *and* also a "private" that 
> isn't a counterpart to other languages' "private" was too idiosyncratic and 
> actively confusing.

Ahh, yes.  I remember this being discussed.  I think that we have learned a lot 
since this discussion took place.  I think it puts too much weight on what 
other languages do and not enough on what is right for Swift where extensions 
are used pervasively to organize code.  

The worst case scenario for someone coming from a C-style language who doesn't 
understand the nuances of Swift yet is that they use `private` and the entity 
has broader visibility than expected, but still within the same file.  Given 
the volume of support for the argument that access control within the same file 
isn't important I think it's safe to say that the consequences of this 
misunderstanding are not that big a deal.  If the developer cares about such 
things they will learn about `scoped` soon enough.

> 
> If I recall, the proposal as submitted for core team review actually proposed 
> something like you suggest, and it was the core team that decided to change 
> it on review.

Yes, it didn't touch `private` and used `local` for scoped access which was a 
bad name for many reasons.  The conversation had always called it "scoped 
access" informally.  I think `scoped` would make a good name for it and find it 
pretty unfortunate that it wasn't spelled that way in the initial proposal. 

> 
> 
>> On Fri, Feb 17, 2017 at 16:36 Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> > 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 
>> >> latter group is less important than the former, and can be handled by 
>> >> convention. Whereas other users of your module definitely benefit from 
>> >> access control and being able to consume a clearly-defined interface.
>> >
>> > I think failing to provide some sort of below-`internal` privacy would be 
>> > missing *really* low-hanging fruit for no good reason. The languages I can 
>> > think of which don't include some sort of sub-library-wide privacy 
>> > level—Objective-C, Javascript, Perl, Python—usually have very simple 
>> > object designs with a flat namespace. (Well, there's Rust, but Rust lets 
>> > you wrap anything you'd like in a module.) Even Objective-C in practice 
>> > includes a `fileprivate` equivalent in the form of methods declared only 
>> > in the .m file.
>> >
>> > I also think it's often helpful to be able to change a member's access 
>> > level without having to change all references to it. Publishing or 
>> > privatizing an interface is not an uncommon refactoring.
>> >
>> > Not everybody likes our current semantics, but that's no reason to throw 
>> > the feature out entirely.
>> 
>> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
>> we can reconsider using `scoped` as the keyword for scoped access rather 
>> than abandoning it.  Does anyone remember why this was considered a bad idea?
>> 
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

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 better and not conflict with existing 
>> Swift syntax.
>> There must be a reasonably automatable migration path for existing code.
> 
> 
> I don’t think there is evidence that scope private in Swift3 is "actively 
> harmful”. 
> Reverting to Swift2 file-private as private is not clearly better. 
> The community has not converged on a clear winner. 
> 
> The only positive thing here is that if we get rid of scope private then it 
> will be easy to make private alias to file-private so no code will break, but 
> we would be removing a feature so I would think this is a breaking change. 
> 
> Would removing private and fileprivate by making them alias to internal also 
> be a breaking change? Even if the code will still compile?

Thanks for posting this Jose.  I think the point that has near unanimous 
agreement is that assigning `private` the meaning of scoped access was a 
mistake.  `fileprivate` is too awkward given how frequently it is necessary in 
common idioms of Swift code organization.  

Whether scoped access itself is a valuable feature and whether it should remain 
is the question that is turning out to be very controversial.  The mistake we 
made with the keywords in Swift 3 certainly didn't help make the case for it.  

That's why I would like to see us try to fix that mistake.  I think everyone 
can be reasonably happy if we can all use `private` the way we did in Swift 2 
and `scoped` can become a style issue.  Some teams can have a linter reject it 
and those of us who like it can continue using it.  As a bonus, we would 
eliminate an awkward keyword.

> 
> This is a linter problem. If people don’t want other people in their team to 
> use scope private then make it part of the coding style. 
> 
> If people do not want fileprivate because it looks ugly, then force everybody 
> to use scope private using a linter like swiftlint. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
 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 
 latter group is less important than the former, and can be handled by 
 convention. Whereas other users of your module definitely benefit from 
 access control and being able to consume a clearly-defined interface.
>>> 
>>> I think failing to provide some sort of below-`internal` privacy would be 
>>> missing *really* low-hanging fruit for no good reason. The languages I can 
>>> think of which don't include some sort of sub-library-wide privacy 
>>> level—Objective-C, Javascript, Perl, Python—usually have very simple object 
>>> designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
>>> anything you'd like in a module.) Even Objective-C in practice includes a 
>>> `fileprivate` equivalent in the form of methods declared only in the .m 
>>> file.
>>> 
>>> I also think it's often helpful to be able to change a member's access 
>>> level without having to change all references to it. Publishing or 
>>> privatizing an interface is not an uncommon refactoring.
>>> 
>>> Not everybody likes our current semantics, but that's no reason to throw 
>>> the feature out entirely.
>> 
>> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
>> we can reconsider using `scoped` as the keyword for scoped access rather 
>> than abandoning it.  Does anyone remember why this was considered a bad idea?
>> 
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

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 
>>>  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 own intentional acts.
>> 
>> Yesterday I stated one intention. Today I (or a coworker) act with a 
>> contradictory intention.
>> 
>> One of these intentions, or some underlying assumption, must be in error.
> 
> Must it? Contradiction != error. I can simultaneously not want to expose a 
> member as the vendor of the API *and* want to invoke the same member as the 
> consumer of the API. Why must I be in error?
>  
>> Why would I want to rely on a human to notice the error, if I can make the 
>> compiler do it?
>> 
>> It is normal to want the compiler to catch my errors. It is strange to 
>> prefer finding errors manually.
> 
> I can agree that compilers should catch errors. I want to persuade you that 
> what we are talking about here does not fall into the category of error.

I don't view it so much as an error as I do a great tool to communicate 
compiler verified intent across time (to future readers and to your future 
self).  As with many things in programming, the value of this is subjective (or 
at least subject of plentiful debate).  I personally find it quite useful and 
it's clear that I am not alone.  On the other hand, it's clear that many people 
don't find it terribly useful.

> 
>> You might persuade me that the cost (in language complexity) of having the 
>> compiler detect the contradiction outweighs the benefit.
>> 
>> But I doubt you can persuade me that the detection has no benefit.
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

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 path for existing code.


I don’t think there is evidence that scope private in Swift3 is "actively 
harmful”. 
Reverting to Swift2 file-private as private is not clearly better. 
The community has not converged on a clear winner. 

The only positive thing here is that if we get rid of scope private then it 
will be easy to make private alias to file-private so no code will break, but 
we would be removing a feature so I would think this is a breaking change. 

Would removing private and fileprivate by making them alias to internal also be 
a breaking change? Even if the code will still compile?

This is a linter problem. If people don’t want other people in their team to 
use scope private then make it part of the coding style. 

If people do not want fileprivate because it looks ugly, then force everybody 
to use scope private using a linter like swiftlint. 



















> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> 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 
>>> latter group is less important than the former, and can be handled by 
>>> convention. Whereas other users of your module definitely benefit from 
>>> access control and being able to consume a clearly-defined interface.
>> 
>> I think failing to provide some sort of below-`internal` privacy would be 
>> missing *really* low-hanging fruit for no good reason. The languages I can 
>> think of which don't include some sort of sub-library-wide privacy 
>> level—Objective-C, Javascript, Perl, Python—usually have very simple object 
>> designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
>> anything you'd like in a module.) Even Objective-C in practice includes a 
>> `fileprivate` equivalent in the form of methods declared only in the .m file.
>> 
>> I also think it's often helpful to be able to change a member's access level 
>> without having to change all references to it. Publishing or privatizing an 
>> interface is not an uncommon refactoring.
>> 
>> Not everybody likes our current semantics, but that's no reason to throw the 
>> feature out entirely.
> 
> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
> we can reconsider using `scoped` as the keyword for scoped access rather than 
> abandoning it.  Does anyone remember why this was considered a bad idea?
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 called is an _intentional_ act. It is strange that you would
>> demand the compiler to stand between two of your own intentional acts.
>
>
> Yesterday I stated one intention. Today I (or a coworker) act with a
> contradictory intention.
>
> One of these intentions, or some underlying assumption, must be in error.
>

Must it? Contradiction != error. I can simultaneously not want to expose a
member as the vendor of the API *and* want to invoke the same member as the
consumer of the API. Why must I be in error?


> Why would I want to rely on a human to notice the error, if I can make the
> compiler do it?
>
> It is normal to want the compiler to catch my errors. It is strange to
> prefer finding errors manually.
>

I can agree that compilers should catch errors. I want to persuade you that
what we are talking about here does not fall into the category of error.

You might persuade me that the cost (in language complexity) of having the
> compiler detect the contradiction outweighs the benefit.
>
> But I doubt you can persuade me that the detection has no benefit.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rob Mayoff via swift-evolution]

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 own intentional acts.


Yesterday I stated one intention. Today I (or a coworker) act with a
contradictory intention.

One of these intentions, or some underlying assumption, must be in error.

Why would I want to rely on a human to notice the error, if I can make the
compiler do it?

It is normal to want the compiler to catch my errors. It is strange to
prefer finding errors manually.

You might persuade me that the cost (in language complexity) of having the
compiler detect the contradiction outweighs the benefit.

But I doubt you can persuade me that the detection has no benefit.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 *and* also a "private" that
isn't a counterpart to other languages' "private" was too idiosyncratic and
actively confusing.

If I recall, the proposal as submitted for core team review actually
proposed something like you suggest, and it was the core team that decided
to change it on review.


On Fri, Feb 17, 2017 at 16:36 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> 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 module definitely benefit from
> access control and being able to consume a clearly-defined interface.
> >
> > I think failing to provide some sort of below-`internal` privacy would
> be missing *really* low-hanging fruit for no good reason. The languages I
> can think of which don't include some sort of sub-library-wide privacy
> level—Objective-C, Javascript, Perl, Python—usually have very simple object
> designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap
> anything you'd like in a module.) Even Objective-C in practice includes a
> `fileprivate` equivalent in the form of methods declared only in the .m
> file.
> >
> > I also think it's often helpful to be able to change a member's access
> level without having to change all references to it. Publishing or
> privatizing an interface is not an uncommon refactoring.
> >
> > Not everybody likes our current semantics, but that's no reason to throw
> the feature out entirely.
>
> +1.  I’d like to see `private` revert to the Swift 2 meaning, and
> hopefully we can reconsider using `scoped` as the keyword for scoped access
> rather than abandoning it.  Does anyone remember why this was considered a
> bad idea?
>
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 
>> latter group is less important than the former, and can be handled by 
>> convention. Whereas other users of your module definitely benefit from 
>> access control and being able to consume a clearly-defined interface.
> 
> I think failing to provide some sort of below-`internal` privacy would be 
> missing *really* low-hanging fruit for no good reason. The languages I can 
> think of which don't include some sort of sub-library-wide privacy 
> level—Objective-C, Javascript, Perl, Python—usually have very simple object 
> designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
> anything you'd like in a module.) Even Objective-C in practice includes a 
> `fileprivate` equivalent in the form of methods declared only in the .m file.
> 
> I also think it's often helpful to be able to change a member's access level 
> without having to change all references to it. Publishing or privatizing an 
> interface is not an uncommon refactoring.
> 
> Not everybody likes our current semantics, but that's no reason to throw the 
> feature out entirely.

+1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully we 
can reconsider using `scoped` as the keyword for scoped access rather than 
abandoning it.  Does anyone remember why this was considered a bad idea?

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 module definitely benefit from access 
> control and being able to consume a clearly-defined interface.

I think failing to provide some sort of below-`internal` privacy would be 
missing *really* low-hanging fruit for no good reason. The languages I can 
think of which don't include some sort of sub-library-wide privacy 
level—Objective-C, Javascript, Perl, Python—usually have very simple object 
designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
anything you'd like in a module.) Even Objective-C in practice includes a 
`fileprivate` equivalent in the form of methods declared only in the .m file.

I also think it's often helpful to be able to change a member's access level 
without having to change all references to it. Publishing or privatizing an 
interface is not an uncommon refactoring.

Not everybody likes our current semantics, but that's no reason to throw the 
feature out entirely.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> 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 email in this thread. with current 'private' 
> he can *guarantee* that no code touches internal props even in the same 
> file), also many of us need a way to share some details only for 
> extensions/subtypes in other files in the same module/submodule even just 
> to organize code as *one* need/want and to express intention about who 
> should "touch" this code and get help from compiler when accidentally try 
> to use protected method/prop.
> 
> Someone, who want just internal/public can use only them in own code, no 
> problems. But many feels that they need a more detailed access levels to 
> structure their code, they find current situation not comfortable.

But I agree with you that there really is a need for better, what I would call, 
entity-based visibility.

In several other OO languages, this is not considered a problem and I fail to 
see why Swift should be any different, apart from the desire on some sides to 
make it different just for the sake of difference.

In a class hierarchy, I can declare stuff as private, knowing full well that 
nobody, but nobody, can "see" or touch that stuff outside of the declaring 
class. That is of paramount importance and central to the concept of 
information hiding.

In a class hierarchy, there is stuff that I want to hide from everybody and 
everything, except those classes that belong to the same hierarchy, which are 
allowed to have privileged access.

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 be overridden by subclasses but, most definitely, 
not callable from any code outside of that hierarchy. For that, I express that 
intent by declaring such stuff as protected, thus preventing "unauthorised" use 
from outside the intended hierarchy.

And, it is in this respect, with the predominance of protocols and structs in 
Swift, that I want to express the same limitations of access to within any type 
(class, struct, enum) that implements a given protocol, or to within any 
extension to any type.

We are allowed to declare base functionality in an extension to a protocol, in 
much the same way as we would in an abstract class.

The difference between Swift protocols and abstract classes is that, with Swift 
protocols, I cannot, presently, limit access to "base" behaviour in the same 
way that I can in an abstract class. On the other hand, I cannot allow 
implementing types or extensions to access those base behaviours unless I put 
them in the same code file as the declaring protocol.

I am perfectly comfortable with the idea of module scope but fail to see the 
point of fileprivate scope, part from as a workaround to the lack of protected 
scope.

As you say, the purpose of scope/visibility is to inform and direct others of 
how your code is intended to be used. There are situations when internal scope 
is simply too great and private scope is too restricted ; as is fileprivate 
even (unless you don't mind bloated, monolithic files).

I believe that what you and I are not arguing for, is the introduction of what 
used to be called protected scope, as found only in classes ; in these days of 
protocols and structs, that would be too limiting and, by implication, more 
relevant to classes only.

Instead, for the wider gamut of types and increased focus on protocols instead 
of abstract classes, what is needed is the same kind of scope that will work 
with both class hierarchies and protocols and their extensions or 
implementations.

Thus, I would confirm that I would prefer to see a simple range of scopes :

1. private - only visible within the declaring type, including nested types.

2. extensible (formerly protected for classes) - visible within the declaring 
type plus : 
  a. for classes, visible in subclasses or extensions
  b. for protocols, structs and enums, visible in extensions to the declaring 
type

3. internal - visible within the declaring module

4. public - does what it says on the tin ; visible anywhere, both inside and 
outside the declaring module

5. removal of fileprivate as an excuse for not having extensible

I would also remind readers of the current peculiar situation with classes in 
Swift, where we have both final classes that totally prohibit derivation, but 
also a mishmash of scope and inheritance restriction with open and public.

Why is it that classes have both entity-based and module-based restriction on 
their derivation? What is wrong with just using final for those classes that we 
do not want to be derived from? I would rather see the extensible scope for 
"derivation" both inside and outs

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

[Xiaodi Wu via swift-evolution]

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 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 of tackling that issue, these are
 suggestions to
 invent ad-hoc units of code (scope + extensions only in the same file,
 scope + extensions only in the same module, class + extensions only in
 the
 same file + subclasses only in the same module), and it is possible to
 invent arbitrary many of these.

>>>
>>> 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 email in this thread. with current 'private'
>>> he can *guarantee* that no code touches internal props even in the same
>>> file), also many of us need a way to share some details only for
>>> extensions/subtypes in other files in the same module/submodule even just
>>> to organize code as *one* need/want and to express intention about who
>>> should "touch" this code and get help from compiler when accidentally try
>>> to use protected method/prop.
>>>
>>
>> I reject the premise that it is a goal of the Swift compiler to protect
>> you from yourself.
>>
>
> I should clarify, it should certainly protect you from unintentional
> accidents that you make, where those are foreseeable, etc. But here we're
> talking about _you_ invoking functions that _you_ wrote, which is a pretty
> darn clear demonstration of intentionality. And so what I mean to say is
> that the Swift compiler, IMO, has no real business trying to protect your
> intentions from your other intentions.
>
>
> With all due respect (and I do respect you as a person with quite an
> insight), why does Swift then (by default) check for (U)Int overflows,
> against nil values, etc, etc. These are all things that are quite
> protecting you from yourself. In a perfect world, you code your stuff in a
> way where you don't need these checks as you'd write code that would handle
> these scenarios. Oh wait, that's Objective-C...
>

Overflow, nil values, etc., all go to Swift's promising of memory safety by
default. They also reflect errors of omission: we unintentionally forget to
handle these cases. 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 own
intentional acts.


> In a similar sense, I believe the compiler/language should prevent you
> from accidently accessing members that are not designed to be accessed from
> out of certain scope.
>
> It's not just to protect _you_ from invoking something not being meant to
> invoke, but others as well.
>

Others that are part of the collective "you" working on the project, the
group of people who have permissions to touch the source code.


> Documentation is perfect only in a perfect world. I can't count how many
> times I've come to a project without a single line of comment, not to
> mention a comment indicating whether the member is meant to be called
> outside of the file, or if it's marked as internal due to current
> limitations in access control and it's simply because you needed to split
> the class amongst several files logic-wise to prevent a bloated single file.
>
> Documentation is not the answer.
>

If documentation is not the answer, then by that line of reasoning, neither
is access control. An author who can't be bothered to document that
something shouldn't be used won't be bothered to determine what an
appropriate access modifier would be, either. My point is that additional
access modifiers don't help you express yourself any more than
documentation does. Put another way, the access modifiers you advocate for
are simply an alternative spelling for a comment.


You can *guarantee* that nothing in the same file touches what it shouldn't
>> touch *by your own eyes*; `private` makes it "easier" but it is by no means
>> necessary. Indeed I argue that reading code should be the go-to way reason
>> about the behavior of code, and that compiler help is justified only when
>> such a method of reasoning is unusually hard or error-prone.
>>
>> Likewise, you can express intention by documentation. Indeed I argue that
>> reading the documentation should be the go-to way for a reader to learn how
>> to use unfamiliar code. Since a user will consult the documentation if he
>> or she is wondering, "how or when should I use this metho

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

[Charlie Monroe via swift-evolution]

> On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 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 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,
> scope + extensions only in the same module, class + extensions only in the
> same file + subclasses only in the same module), and it is possible to
> invent arbitrary many of these.
> 
> 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 email in this thread. with current 'private' he can 
> *guarantee* that no code touches internal props even in the same file), also 
> many of us need a way to share some details only for extensions/subtypes in 
> other files in the same module/submodule even just to organize code as *one* 
> need/want and to express intention about who should "touch" this code and get 
> help from compiler when accidentally try to use protected method/prop.
> 
> I reject the premise that it is a goal of the Swift compiler to protect you 
> from yourself.
> 
> I should clarify, it should certainly protect you from unintentional 
> accidents that you make, where those are foreseeable, etc. But here we're 
> talking about _you_ invoking functions that _you_ wrote, which is a pretty 
> darn clear demonstration of intentionality. And so what I mean to say is that 
> the Swift compiler, IMO, has no real business trying to protect your 
> intentions from your other intentions.

With all due respect (and I do respect you as a person with quite an insight), 
why does Swift then (by default) check for (U)Int overflows, against nil 
values, etc, etc. These are all things that are quite protecting you from 
yourself. In a perfect world, you code your stuff in a way where you don't need 
these checks as you'd write code that would handle these scenarios. Oh wait, 
that's Objective-C...

In a similar sense, I believe the compiler/language should prevent you from 
accidently accessing members that are not designed to be accessed from out of 
certain scope.

It's not just to protect _you_ from invoking something not being meant to 
invoke, but others as well.

Documentation is perfect only in a perfect world. I can't count how many times 
I've come to a project without a single line of comment, not to mention a 
comment indicating whether the member is meant to be called outside of the 
file, or if it's marked as internal due to current limitations in access 
control and it's simply because you needed to split the class amongst several 
files logic-wise to prevent a bloated single file.

Documentation is not the answer.

> 
> You can *guarantee* that nothing in the same file touches what it shouldn't 
> touch *by your own eyes*; `private` makes it "easier" but it is by no means 
> necessary. Indeed I argue that reading code should be the go-to way reason 
> about the behavior of code, and that compiler help is justified only when 
> such a method of reasoning is unusually hard or error-prone.
> 
> Likewise, you can express intention by documentation. Indeed I argue that 
> reading the documentation should be the go-to way for a reader to learn how 
> to use unfamiliar code. Since a user will consult the documentation if he or 
> she is wondering, "how or when should I use this method?", it is perfectly 
> sufficient and elegant to put a sentence in the documentation that says, 
> "actually, you should never use this method." It is self-evident why one 
> might _want_ compiler help, but it is unclear to me why one _needs_ compiler 
> help for this: after all, if you call an internal method that doesn't behave 
> as intended, you can read the source code to find out exactly why--you can 
> even change it!
> 
> Someone, who want just internal/public can use only them in own code, no 
> problems. But many feels that they need a more detailed access levels to 
> structure their code, they find current situation not comfortable.
> 
> As I said, there are arbitrarily many ways to structure your code. If you 
> insist that the compiler should help you to control, perfectly, exactly what 
> lines of code can call what other lines of code, and that the way to spell 
> this desire is through access levels, then you will need many more access 
> levels. My point is that, taken to its logical end, you would need infinitely 
> many access levels. Although it would be unnecessary for the language to 
> ac

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

[David Sweeris via swift-evolution]

> 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 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. 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
> only. No private, no fileprivate, no lineprivate, no protected.
> It’s all silly.
 
 Eh, I've used `private` to keep myself honest in terms of going
 through some book-keeping functions instead of directly accessing a
 property.
>>> 
>>> But is that not an argument to get rid of ‘private’ & ‘fileprivate’?
>>> 
>>> With great power there comes great responsibility ;-)
>> 
>> I don't see how... I used `private` on some dicts that interact with
>> each other (faking a lightweight database) to ensure I was using my
>> type's subscript functions (which handle updating all the dicts
>> correctly) instead of directly accessing the dictionaries in some areas
>> where the interactions theoretically wouldn't matter. Since I was able
>> to mark those properties as private, I know that all the access to those
>> properties goes through the proper book-keeping functions. Not only does
>> this reduce the opportunity for bugs, it makes it far simpler to change
>> the implementation later if I decide it should be backed by a "proper"
>> database since everything that directly touches the storage will be
>> right there in the type definition instead of spread through however
>> many extensions across however many files.
>> 
> 
> David, I assume personally you see a benefits of 'private' as it is currently 
> and don't support extending its scope to "type and subtypes and extensions in 
> the same module"? My suggestion was to extend it…

I wouldn’t mind something synonymous with C++’s “friend”, although I don’t 
really have an opinion on the spelling. Right now, I use “fileprivate” to kinda 
fake it by putting everything that needs access to property/function in 
question in the same file. That approach doesn’t really scale well (or at all, 
if you want to publish a class that you intend your clients to subclass), but 
so far the codebase I’m using it in is small enough that’s just an annoyance 
rather than an actual issue.

> Personally I'd like to have a way to say all of this as access scope(in 
> addition to current public/internal/fileprivate):
> 1. type only
> 2. type and subtypes in the same module
> 3. type and subtypes and extensions in the same module
> 4. file and subtypes in the same module
> 5. file and subtypes and extensions in the same module
> 
> Probably we could have just (3) without (2), and (5) without (4), need to 
> discuss if it is important to be able to provide access to subtype but not 
> for extensions.
> 
> So, it seems for me like we need to return 'public' keyword where it was in 
> Swift2(so to have public/internal/private "file"-based scope), and introduce 
> well-designed scope access levels with own keywords.
> 
> For example, if we really need just (3) and just (5) (without 2 and 4):
> typeprivate - type only
> typeprotected - type and subtypes and extensions in the same module
> typeinternal - file and subtypes and extensions in the same module
> 
> Opinions?

Personally, I’d prefer “access(option)” over “optionaccess”, but I’m more 
interested in getting agreement on the functionality than how it’s spelled. My 
only strong feeling on the matter of spelling is that it should be clear and 
consistent… “davesCrutch”, while arguably accurate, would be a horrible name 
because its meaning is so unclear, and even though it’d be my preferred 
spelling, I would be opposed to adding “private(type)” unless we also replace 
“fileprivate” with “private(file)”.

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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 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
complications that only serve to clutter the language.

It would make a lot more sense to just have internal and public
only. No private, no fileprivate, no lineprivate, no protected.
It’s all silly.


Eh, I've used `private` to keep myself honest in terms of going
through some book-keeping functions instead of directly accessing a
property.


But is that not an argument to get rid of ‘private’ & ‘fileprivate’?

With great power there comes great responsibility ;-)


I don't see how... I used `private` on some dicts that interact with
each other (faking a lightweight database) to ensure I was using my
type's subscript functions (which handle updating all the dicts
correctly) instead of directly accessing the dictionaries in some areas
where the interactions theoretically wouldn't matter. Since I was able
to mark those properties as private, I know that all the access to those
properties goes through the proper book-keeping functions. Not only does
this reduce the opportunity for bugs, it makes it far simpler to change
the implementation later if I decide it should be backed by a "proper"
database since everything that directly touches the storage will be
right there in the type definition instead of spread through however
many extensions across however many files.



David, I assume personally you see a benefits of 'private' as it is 
currently and don't support extending its scope to "type and subtypes and 
extensions in the same module"? My suggestion was to extend it...


Personally I'd like to have a way to say all of this as access scope(in 
addition to current public/internal/fileprivate):

1. type only
2. type and subtypes in the same module
3. type and subtypes and extensions in the same module
4. file and subtypes in the same module
5. file and subtypes and extensions in the same module

Probably we could have just (3) without (2), and (5) without (4), need to 
discuss if it is important to be able to provide access to subtype but not 
for extensions.


So, it seems for me like we need to return 'public' keyword where it was in 
Swift2(so to have public/internal/private "file"-based scope), and 
introduce well-designed scope access levels with own keywords.


For example, if we really need just (3) and just (5) (without 2 and 4):
typeprivate - type only
typeprotected - type and subtypes and extensions in the same module
typeinternal - file and subtypes and extensions in the same module

Opinions?


- Dave Sweeris ___
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 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,
>>> scope + extensions only in the same module, class + extensions only in
>>> the
>>> same file + subclasses only in the same module), and it is possible to
>>> invent arbitrary many of these.
>>>
>>
>> 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 email in this thread. with current 'private'
>> he can *guarantee* that no code touches internal props even in the same
>> file), also many of us need a way to share some details only for
>> extensions/subtypes in other files in the same module/submodule even just
>> to organize code as *one* need/want and to express intention about who
>> should "touch" this code and get help from compiler when accidentally try
>> to use protected method/prop.
>>
>
> I reject the premise that it is a goal of the Swift compiler to protect
> you from yourself.
>

I should clarify, it should certainly protect you from unintentional
accidents that you make, where those are foreseeable, etc. But here we're
talking about _you_ invoking functions that _you_ wrote, which is a pretty
darn clear demonstration of intentionality. And so what I mean to say is
that the Swift compiler, IMO, has no real business trying to protect your
intentions from your other intentions.

You can *guarantee* that nothing in the same file touches what it shouldn't
> touch *by your own eyes*; `private` makes it "easier" but it is by no means
> necessary. Indeed I argue that reading code should be the go-to way reason
> about the behavior of code, and that compiler help is justified only when
> such a method of reasoning is unusually hard or error-prone.
>
> Likewise, you can express intention by documentation. Indeed I argue that
> reading the documentation should be the go-to way for a reader to learn how
> to use unfamiliar code. Since a user will consult the documentation if he
> or she is wondering, "how or when should I use this method?", it is
> perfectly sufficient and elegant to put a sentence in the documentation
> that says, "actually, you should never use this method." It is self-evident
> why one might _want_ compiler help, but it is unclear to me why one _needs_
> compiler help for this: after all, if you call an internal method that
> doesn't behave as intended, you can read the source code to find out
> exactly why--you can even change it!
>
> Someone, who want just internal/public can use only them in own code, no
>> problems. But many feels that they need a more detailed access levels to
>> structure their code, they find current situation not comfortable.
>>
>
> As I said, there are arbitrarily many ways to structure your code. If you
> insist that the compiler should help you to control, perfectly, exactly
> what lines of code can call what other lines of code, and that the way to
> spell this desire is through access levels, then you will need many more
> access levels. My point is that, taken to its logical end, you would need
> infinitely many access levels. Although it would be unnecessary for the
> language to active prohibit certain styles of organizing code, I believe
> very strongly it is a non-goal of Swift to actively support, by the
> addition of new features, all imaginable styles of organizing code.
>
>
>
>>
>>
>>> There is, objectively, an actual minimum number of access modifiers,
>>> which
>>> is two. Those two are: visible only inside the unit of code, or visible
>>> both inside and outside the unit of code. In Swift, those are spelled
>>> internal and public. Everything else here is really talking about better
>>> or
>>> more flexible ways of defining a unit of code.
>>>
>>>
>>> On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution
>>> mailto:swift-evolution@swift.org>> wrote:
>>>
>>> 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
>>> >> mailto:swift-evolution@swift.org>
>>> >> >>>
>>>
>>> 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 fact
>>> that I'm
>>> >> unnecessarily exp

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

[Xiaodi Wu via swift-evolution]

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 of tackling that issue, these are suggestions
>> to
>> invent ad-hoc units of code (scope + extensions only in the same file,
>> scope + extensions only in the same module, class + extensions only in the
>> same file + subclasses only in the same module), and it is possible to
>> invent arbitrary many of these.
>>
>
> 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 email in this thread. with current 'private'
> he can *guarantee* that no code touches internal props even in the same
> file), also many of us need a way to share some details only for
> extensions/subtypes in other files in the same module/submodule even just
> to organize code as *one* need/want and to express intention about who
> should "touch" this code and get help from compiler when accidentally try
> to use protected method/prop.
>

I reject the premise that it is a goal of the Swift compiler to protect you
from yourself.

You can *guarantee* that nothing in the same file touches what it shouldn't
touch *by your own eyes*; `private` makes it "easier" but it is by no means
necessary. Indeed I argue that reading code should be the go-to way reason
about the behavior of code, and that compiler help is justified only when
such a method of reasoning is unusually hard or error-prone.

Likewise, you can express intention by documentation. Indeed I argue that
reading the documentation should be the go-to way for a reader to learn how
to use unfamiliar code. Since a user will consult the documentation if he
or she is wondering, "how or when should I use this method?", it is
perfectly sufficient and elegant to put a sentence in the documentation
that says, "actually, you should never use this method." It is self-evident
why one might _want_ compiler help, but it is unclear to me why one _needs_
compiler help for this: after all, if you call an internal method that
doesn't behave as intended, you can read the source code to find out
exactly why--you can even change it!

Someone, who want just internal/public can use only them in own code, no
> problems. But many feels that they need a more detailed access levels to
> structure their code, they find current situation not comfortable.
>

As I said, there are arbitrarily many ways to structure your code. If you
insist that the compiler should help you to control, perfectly, exactly
what lines of code can call what other lines of code, and that the way to
spell this desire is through access levels, then you will need many more
access levels. My point is that, taken to its logical end, you would need
infinitely many access levels. Although it would be unnecessary for the
language to active prohibit certain styles of organizing code, I believe
very strongly it is a non-goal of Swift to actively support, by the
addition of new features, all imaginable styles of organizing code.



>
>
>> There is, objectively, an actual minimum number of access modifiers, which
>> is two. Those two are: visible only inside the unit of code, or visible
>> both inside and outside the unit of code. In Swift, those are spelled
>> internal and public. Everything else here is really talking about better
>> or
>> more flexible ways of defining a unit of code.
>>
>>
>> On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> 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
>> >> mailto:swift-evolution@swift.org>
>> > >>>
>>
>> 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 fact
>> that I'm
>> >> unnecessarily exposing an internal implementation detail to the
>> rest of
>> >> the module. Being able to hide it from the rest IMHO leads to
>> better
>> >> though-through API that is indeed meant to be exposed; whereas
>> exposing
>> >> internal details leads to allowing various quick hacks instead. We
>> know
>> >> these quick hacks very well from the ObjC world by accessing
>> private
>> >> parts of the object via duck typing or setting values via KVO.
>> >>
>> >> At least this is my experience with which the less implementation
>> details
>> >> are exposed t

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

[Vladimir.S via swift-evolution]

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 + extensions only in the same file,
scope + extensions only in the same module, class + extensions only in the
same file + subclasses only in the same module), and it is possible to
invent arbitrary many of these.


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 email in this thread. with current 'private' 
he can *guarantee* that no code touches internal props even in the same 
file), also many of us need a way to share some details only for 
extensions/subtypes in other files in the same module/submodule even just 
to organize code as *one* need/want and to express intention about who 
should "touch" this code and get help from compiler when accidentally try 
to use protected method/prop.


Someone, who want just internal/public can use only them in own code, no 
problems. But many feels that they need a more detailed access levels to 
structure their code, they find current situation not comfortable.





There is, objectively, an actual minimum number of access modifiers, which
is two. Those two are: visible only inside the unit of code, or visible
both inside and outside the unit of code. In Swift, those are spelled
internal and public. Everything else here is really talking about better or
more flexible ways of defining a unit of code.


On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

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
>> mailto:swift-evolution@swift.org>
>>
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 fact
that I'm
>> unnecessarily exposing an internal implementation detail to the rest of
>> the module. Being able to hide it from the rest IMHO leads to better
>> though-through API that is indeed meant to be exposed; whereas exposing
>> internal details leads to allowing various quick hacks instead. We know
>> these quick hacks very well from the ObjC world by accessing private
>> parts of the object via duck typing or setting values via KVO.
>>
>> At least this is my experience with which the less implementation
details
>> are exposed to the outer world, the better.
>
> I think the fundamental disagreement we’re seeing in this thread is the
> meaning of “outer world”; to some, it means “users of your module”. To
> others, it also means “other developers on my team who are working on
other
> files in the module”.
>
> 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 module definitely benefit from
> access control and being able to consume a clearly-defined interface.

I assume we are discussing access modifiers mainly for the former group,
i.e. when we are "inside" the module (even when this module is written by
the same one person, and especially when it is written by the group).

"handled by convention" - are we talking about something like declaring
props and methods as __privateprop , m_privateprop etc and write comments
to mark that they should not be used outside of some scope? Is it really
Swifty and acceptable for the modern language? Will this help to prevent
some mistakes with incorrect access? Is it better than simple and clean
schema for access modifiers and compiler's help?  I don't understand this.

IMO, access modifiers is very known and handy abstraction to distinct
levels of access and to structure code many developers knows about and use
in other languages.
At the end, if one wants to keep all internal - no problems!, you can do
this right now, just don't use fileprivate/private/etc.

Yes, I agree we need a simple and clean schema, not over-complicated, we
need nice&clean keywords, we need a required minimum of access modifiers,
not more, and I do believe currently we don't have this minimum.

Was already suggested, trying again(I do believe this could be a
compromised solution to suit needs of the main part of developers):
* (as currently) publi

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

[David Sweeris via swift-evolution]

> 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 that issue, these are suggestions to 
> invent ad-hoc units of code (scope + extensions only in the same file, scope 
> + extensions only in the same module, class + extensions only in the same 
> file + subclasses only in the same module), and it is possible to invent 
> arbitrary many of these.
> 
> There is, objectively, an actual minimum number of access modifiers, which is 
> two. Those two are: visible only inside the unit of code, or visible both 
> inside and outside the unit of code. In Swift, those are spelled internal and 
> public. Everything else here is really talking about better or more flexible 
> ways of defining a unit of code.

Wasn’t there a thread about submodules a while back? I’m pretty sure I remember 
reading some back and forth about it here, but I don’t recall any conclusions.

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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,
scope + extensions only in the same module, class + extensions only in the
same file + subclasses only in the same module), and it is possible to
invent arbitrary many of these.

There is, objectively, an actual minimum number of access modifiers, which
is two. Those two are: visible only inside the unit of code, or visible
both inside and outside the unit of code. In Swift, those are spelled
internal and public. Everything else here is really talking about better or
more flexible ways of defining a unit of code.


On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> 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
> >> mailto:swift-evolution@swift.org>> 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 fact that
> I'm
> >> unnecessarily exposing an internal implementation detail to the rest of
> >> the module. Being able to hide it from the rest IMHO leads to better
> >> though-through API that is indeed meant to be exposed; whereas exposing
> >> internal details leads to allowing various quick hacks instead. We know
> >> these quick hacks very well from the ObjC world by accessing private
> >> parts of the object via duck typing or setting values via KVO.
> >>
> >> At least this is my experience with which the less implementation
> details
> >> are exposed to the outer world, the better.
> >
> > I think the fundamental disagreement we’re seeing in this thread is the
> > meaning of “outer world”; to some, it means “users of your module”. To
> > others, it also means “other developers on my team who are working on
> other
> > files in the module”.
> >
> > 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 module definitely benefit from
> > access control and being able to consume a clearly-defined interface.
>
> I assume we are discussing access modifiers mainly for the former group,
> i.e. when we are "inside" the module (even when this module is written by
> the same one person, and especially when it is written by the group).
>
> "handled by convention" - are we talking about something like declaring
> props and methods as __privateprop , m_privateprop etc and write comments
> to mark that they should not be used outside of some scope? Is it really
> Swifty and acceptable for the modern language? Will this help to prevent
> some mistakes with incorrect access? Is it better than simple and clean
> schema for access modifiers and compiler's help?  I don't understand this.
>
> IMO, access modifiers is very known and handy abstraction to distinct
> levels of access and to structure code many developers knows about and use
> in other languages.
> At the end, if one wants to keep all internal - no problems!, you can do
> this right now, just don't use fileprivate/private/etc.
>
> Yes, I agree we need a simple and clean schema, not over-complicated, we
> need nice&clean keywords, we need a required minimum of access modifiers,
> not more, and I do believe currently we don't have this minimum.
>
> Was already suggested, trying again(I do believe this could be a
> compromised solution to suit needs of the main part of developers):
> * (as currently) public/open -> outside of the module
> * (as currently) internal -> inside module
> * private -> inside file (instead of fileprivate)
> * protected(or *other* keyword) -> inside file + subtype&extensions in the
> *same module*
>
> What objections could be made for this?
> Thank you.
>
> >
> > Slava
> >
> >>
> >>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu  >>> > wrote:
> >>>
> >>> 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 the documentation before using a variable anyway.
> >>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution
> >>> mailto:swift-evolution@swift.org>> wrote:
> >>>
> >>> 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

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

[David Sweeris via swift-evolution]

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 
>>>  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 complications that 
>>> only serve to clutter the language.
>>> 
>>> It would make a lot more sense to just have internal and public only. No 
>>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>> 
>> Eh, I've used `private` to keep myself honest in terms of going through some 
>> book-keeping functions instead of directly accessing a property.
> 
> But is that not an argument to get rid of ‘private’ & ‘fileprivate’?
> 
> With great power there comes great responsibility ;-)

I don't see how... I used `private` on some dicts that interact with each other 
(faking a lightweight database) to ensure I was using my type's subscript 
functions (which handle updating all the dicts correctly) instead of directly 
accessing the dictionaries in some areas where the interactions theoretically 
wouldn't matter. Since I was able to mark those properties as private, I know 
that all the access to those properties goes through the proper book-keeping 
functions. Not only does this reduce the opportunity for bugs, it makes it far 
simpler to change the implementation later if I decide it should be backed by a 
"proper" database since everything that directly touches the storage will be 
right there in the type definition instead of spread through however many 
extensions across however many files.

- Dave Sweeris 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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
mailto:swift-evolution@swift.org>> 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 fact that I'm
unnecessarily exposing an internal implementation detail to the rest of
the module. Being able to hide it from the rest IMHO leads to better
though-through API that is indeed meant to be exposed; whereas exposing
internal details leads to allowing various quick hacks instead. We know
these quick hacks very well from the ObjC world by accessing private
parts of the object via duck typing or setting values via KVO.

At least this is my experience with which the less implementation details
are exposed to the outer world, the better.


I think the fundamental disagreement we’re seeing in this thread is the
meaning of “outer world”; to some, it means “users of your module”. To
others, it also means “other developers on my team who are working on other
files in the module”.

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 module definitely benefit from
access control and being able to consume a clearly-defined interface.


I assume we are discussing access modifiers mainly for the former group, 
i.e. when we are "inside" the module (even when this module is written by 
the same one person, and especially when it is written by the group).


"handled by convention" - are we talking about something like declaring 
props and methods as __privateprop , m_privateprop etc and write comments 
to mark that they should not be used outside of some scope? Is it really 
Swifty and acceptable for the modern language? Will this help to prevent 
some mistakes with incorrect access? Is it better than simple and clean 
schema for access modifiers and compiler's help?  I don't understand this.


IMO, access modifiers is very known and handy abstraction to distinct 
levels of access and to structure code many developers knows about and use 
in other languages.
At the end, if one wants to keep all internal - no problems!, you can do 
this right now, just don't use fileprivate/private/etc.


Yes, I agree we need a simple and clean schema, not over-complicated, we 
need nice&clean keywords, we need a required minimum of access modifiers, 
not more, and I do believe currently we don't have this minimum.


Was already suggested, trying again(I do believe this could be a 
compromised solution to suit needs of the main part of developers):

* (as currently) public/open -> outside of the module
* (as currently) internal -> inside module
* private -> inside file (instead of fileprivate)
* protected(or *other* keyword) -> inside file + subtype&extensions in the 
*same module*


What objections could be made for this?
Thank you.



Slava




On Feb 17, 2017, at 8:54 AM, Xiaodi Wu mailto:xiaodi...@gmail.com>> wrote:

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 the documentation before using a variable anyway.
On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

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
having a variable internal or cramming all of the class extension
into one file, making it a 3KLOC mess. Either solution is not pretty
- now I have it split among several files with an internal variable
commented as "Do not use, for private use of this class only."


On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez
mailto:ch...@masters3d.com>> wrote:

https://developer.apple.com/swift/blog/?id=11



On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution
mailto:swift-evolution@swift.org>> wrote:


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 the file

@protected internal - again, but you can access it even from
extensions and subclasses outside of the file within the entire
module.

@protected public/open - the same as above, but outside the modules.

To me, 

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

[Rien via swift-evolution]

> 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 
>>  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 complications that 
>> only serve to clutter the language.
>> 
>> It would make a lot more sense to just have internal and public only. No 
>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Eh, I've used `private` to keep myself honest in terms of going through some 
> book-keeping functions instead of directly accessing a property.

But is that not an argument to get rid of ‘private’ & ‘fileprivate’?

With great power there comes great responsibility ;-)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl

> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

> 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 complications that 
> only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Slava

+1

Not because it is silly, and there are uses, but simplification is imo way more 
powerful than questionable features.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> 
>> On Feb 15, 2017, at 7:40 AM, T.J. Usiyan via swift-evolution 
>>  wrote:
>> 
>> "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 
>>  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 
>> > see two plausible meanings for private:
>> >
>> > Private could mean either:
>> > 1) private to the file (Swift 2 semantics)
>> > 2) accessible only to the current type/scope and to extensions to that 
>> > type that are in the current file.
>> >
>> > I don’t think we’ve ever evaluated and debated approach #2 systematically.
>> 
>> For what it's worth:
>> 
>> I was opposed to SE-0025, but since I lost, I have tried to use `private` 
>> wherever it made sense, rather than fighting with the language.
>> 
>> Sometimes, the change of keyword makes no difference. Other times, it's a 
>> hassle, because I have to switch between `private` and `fileprivate` as I 
>> redesign things, with little perceived benefit. I'd say the split between 
>> these is about 50/50.
>> 
>> On a few occasions, I *have* genuinely appreciated the SE-0025 version of 
>> `private`. These involved cases where I wanted to ensure that instance 
>> variables were only manipulated in certain ways, using interfaces I had 
>> specifically designed to handle them correctly. For instance, I might have 
>> two parallel arrays, and I wanted to make sure that I only added or removed 
>> elements from both arrays at once. I could do this with `fileprivate` by 
>> splitting the type into two files, but it was more convenient to do it in 
>> one.
>> 
>> In these cases, switching to #2 would *completely* defeat the purpose of 
>> using `private`, because the extensions would be able to directly manipulate 
>> the private instance variables. I would no longer gain any benefit at all 
>> from `private`. All of my uses would either fall into "makes no difference" 
>> or "it's a hassle".
>> 
>> I do not support the idea of changing `private` to mean #2. Doing so would 
>> eliminate the few decent use cases I've found for `private`. Either keep it 
>> or drop it, but don't keep fiddling with it.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> On Feb 17, 2017, at 9:29 AM, Slava Pestov  wrote:
> 
> 
>> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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 fact that I'm 
>> unnecessarily exposing an internal implementation detail to the rest of the 
>> module. Being able to hide it from the rest IMHO leads to better 
>> though-through API that is indeed meant to be exposed; whereas exposing 
>> internal details leads to allowing various quick hacks instead. We know 
>> these quick hacks very well from the ObjC world by accessing private parts 
>> of the object via duck typing or setting values via KVO.
>> 
>> At least this is my experience with which the less implementation details 
>> are exposed to the outer world, the better.
> 
> I think the fundamental disagreement we’re seeing in this thread is the 
> meaning of “outer world”; to some, it means “users of your module”. To 
> others, it also means “other developers on my team who are working on other 
> files in the module”.

I've come across projects where multiple developers contributed to the project 
over the time, some leaving the company, some coming, thus inheriting the 
project. Those that came to the project at later stages (with the project being 
larger) often tried to use the path of least resistance when fixing 
issues/adding new features, which often resulted in hack-ish code that accessed 
members that were meant to be private to the class but weren't since the 
members were used by subclasses/extensions in other files, etc. (things 
solvable by extensions).

If these members were protected, the developer wouldn't be able to access them 
and it would encourage a discussion on why the member is protected and if there 
is a "cleaner" way to do this. That's why I'm saying that the correct access 
control encourages cleaner code and better public APIs. Even when "public" 
means "internal" (as in within one module).

I totally agree that it's a lot depending on the team and the people, but you 
can't always control everyone all the time and that's where the language should 
help and guide.

> 
> 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 module definitely benefit from access 
> control and being able to consume a clearly-defined interface.
> 
> Slava
> 
>> 
>>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu >> > wrote:
>>> 
>>> 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 the documentation before using a variable anyway.
>>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 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 having a variable 
>>> internal or cramming all of the class extension into one file, making it a 
>>> 3KLOC mess. Either solution is not pretty - now I have it split among 
>>> several files with an internal variable commented as "Do not use, for 
>>> private use of this class only."
>>> 
 On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez >>> > wrote:
 
 https://developer.apple.com/swift/blog/?id=11 
 
 
 
 
 On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> 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 the file
> 
> @protected internal - again, but you can access it even from extensions 
> and subclasses outside of the file within the entire module.
> 
> @protected public/open - the same as above, but outside the modules.
> 
> To me, this way most people here will be happy:
> 
> - those wishing the access control gets simplified - it in fact does, you 
> don't need to use @protected, if you don't want to/need to.
> - those who need a fine-grained solution, here

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

[Slava Pestov via swift-evolution]

> 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 fact that I'm 
> unnecessarily exposing an internal implementation detail to the rest of the 
> module. Being able to hide it from the rest IMHO leads to better 
> though-through API that is indeed meant to be exposed; whereas exposing 
> internal details leads to allowing various quick hacks instead. We know these 
> quick hacks very well from the ObjC world by accessing private parts of the 
> object via duck typing or setting values via KVO.
> 
> At least this is my experience with which the less implementation details are 
> exposed to the outer world, the better.

I think the fundamental disagreement we’re seeing in this thread is the meaning 
of “outer world”; to some, it means “users of your module”. To others, it also 
means “other developers on my team who are working on other files in the 
module”.

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 module definitely benefit from access control and 
being able to consume a clearly-defined interface.

Slava

> 
>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu > > wrote:
>> 
>> 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 the documentation before using a variable anyway.
>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 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 having a variable 
>> internal or cramming all of the class extension into one file, making it a 
>> 3KLOC mess. Either solution is not pretty - now I have it split among 
>> several files with an internal variable commented as "Do not use, for 
>> private use of this class only."
>> 
>>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez >> > wrote:
>>> 
>>> https://developer.apple.com/swift/blog/?id=11 
>>> 
>>> 
>>> 
>>> 
>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 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 the file
 
 @protected internal - again, but you can access it even from extensions 
 and subclasses outside of the file within the entire module.
 
 @protected public/open - the same as above, but outside the modules.
 
 To me, this way most people here will be happy:
 
 - those wishing the access control gets simplified - it in fact does, you 
 don't need to use @protected, if you don't want to/need to.
 - those who need a fine-grained solution, here it is.
 
 
 
> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 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 complications 
>>> that only serve to clutter the language.
>>> 
>>> It would make a lot more sense to just have internal and public only. 
>>> No private, no fileprivate, no lineprivate, no protected. It’s all 
>>> silly.
>> 
>> Eh, I've used `private` to keep myself honest in terms of going through 
>> some book-keeping functions instead of directly accessing a property.
> 
> This is exactly the kind of thing I like it for and why I hope we might 
> be able to keep scoped access even if it gets a new name that ends up as 
> awkward as fileprivate (allow

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

[Charlie Monroe via swift-evolution]

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 it from the rest IMHO leads to better though-through 
API that is indeed meant to be exposed; whereas exposing internal details leads 
to allowing various quick hacks instead. We know these quick hacks very well 
from the ObjC world by accessing private parts of the object via duck typing or 
setting values via KVO.

At least this is my experience with which the less implementation details are 
exposed to the outer world, the better.

> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu  wrote:
> 
> 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 the 
> documentation before using a variable anyway.
> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 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 having a variable 
> internal or cramming all of the class extension into one file, making it a 
> 3KLOC mess. Either solution is not pretty - now I have it split among several 
> files with an internal variable commented as "Do not use, for private use of 
> this class only."
> 
>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez > > wrote:
>> 
>> https://developer.apple.com/swift/blog/?id=11 
>> 
>> 
>> 
>> 
>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 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 the file
>>> 
>>> @protected internal - again, but you can access it even from extensions and 
>>> subclasses outside of the file within the entire module.
>>> 
>>> @protected public/open - the same as above, but outside the modules.
>>> 
>>> To me, this way most people here will be happy:
>>> 
>>> - those wishing the access control gets simplified - it in fact does, you 
>>> don't need to use @protected, if you don't want to/need to.
>>> - those who need a fine-grained solution, here it is.
>>> 
>>> 
>>> 
 On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
 
 Sent from my iPad
 
> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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 complications 
>> that only serve to clutter the language.
>> 
>> It would make a lot more sense to just have internal and public only. No 
>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Eh, I've used `private` to keep myself honest in terms of going through 
> some book-keeping functions instead of directly accessing a property.
 
 This is exactly the kind of thing I like it for and why I hope we might be 
 able to keep scoped access even if it gets a new name that ends up as 
 awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
 
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org

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

[Xiaodi Wu via swift-evolution]

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 the documentation before using a variable anyway.
On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 having a variable
> internal or cramming all of the class extension into one file, making it a
> 3KLOC mess. Either solution is not pretty - now I have it split among
> several files with an internal variable commented as "Do not use, for
> private use of this class only."
>
> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez 
> wrote:
>
> https://developer.apple.com/swift/blog/?id=11
>
>
>
> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 the file
>
> @protected internal - again, but you can access it even from extensions
> and subclasses outside of the file within the entire module.
>
> @protected public/open - the same as above, but outside the modules.
>
> To me, this way most people here will be happy:
>
> - those wishing the access control gets simplified - it in fact does, you
> don't need to use @protected, if you don't want to/need to.
> - those who need a fine-grained solution, here it is.
>
>
>
> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Sent from my iPad
>
> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> 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 complications
> that only serve to clutter the language.
>
> It would make a lot more sense to just have internal and public only. No
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>
>
> Eh, I've used `private` to keep myself honest in terms of going through
> some book-keeping functions instead of directly accessing a property.
>
>
> This is exactly the kind of thing I like it for and why I hope we might be
> able to keep scoped access even if it gets a new name that ends up as
> awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
>
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

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 having a variable 
internal or cramming all of the class extension into one file, making it a 
3KLOC mess. Either solution is not pretty - now I have it split among several 
files with an internal variable commented as "Do not use, for private use of 
this class only."

> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez  wrote:
> 
> https://developer.apple.com/swift/blog/?id=11 
> 
> 
> 
> 
> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 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 the file
>> 
>> @protected internal - again, but you can access it even from extensions and 
>> subclasses outside of the file within the entire module.
>> 
>> @protected public/open - the same as above, but outside the modules.
>> 
>> To me, this way most people here will be happy:
>> 
>> - those wishing the access control gets simplified - it in fact does, you 
>> don't need to use @protected, if you don't want to/need to.
>> - those who need a fine-grained solution, here it is.
>> 
>> 
>> 
>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
> mailto:swift-evolution@swift.org>> 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 complications 
> that only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
 
 Eh, I've used `private` to keep myself honest in terms of going through 
 some book-keeping functions instead of directly accessing a property.
>>> 
>>> This is exactly the kind of thing I like it for and why I hope we might be 
>>> able to keep scoped access even if it gets a new name that ends up as 
>>> awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
>>> 
 
 - Dave Sweeris
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

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 annotation for those 
> who want a more fine-grained solution:
> 
> @protected private - members accessable only from the class/struct/enum/... 
> and their extensions within the file
> 
> @protected internal - again, but you can access it even from extensions and 
> subclasses outside of the file within the entire module.
> 
> @protected public/open - the same as above, but outside the modules.
> 
> To me, this way most people here will be happy:
> 
> - those wishing the access control gets simplified - it in fact does, you 
> don't need to use @protected, if you don't want to/need to.
> - those who need a fine-grained solution, here it is.
> 
> 
> 
>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> 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. 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 only. No 
 private, no fileprivate, no lineprivate, no protected. It’s all silly.
>>> 
>>> Eh, I've used `private` to keep myself honest in terms of going through 
>>> some book-keeping functions instead of directly accessing a property.
>> 
>> This is exactly the kind of thing I like it for and why I hope we might be 
>> able to keep scoped access even if it gets a new name that ends up as 
>> awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
>> 
>>> 
>>> - Dave Sweeris
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

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 the file

@protected internal - again, but you can access it even from extensions and 
subclasses outside of the file within the entire module.

@protected public/open - the same as above, but outside the modules.

To me, this way most people here will be happy:

- those wishing the access control gets simplified - it in fact does, you don't 
need to use @protected, if you don't want to/need to.
- those who need a fine-grained solution, here it is.



> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> 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. 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 only. No 
>>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>> 
>> Eh, I've used `private` to keep myself honest in terms of going through some 
>> book-keeping functions instead of directly accessing a property.
> 
> This is exactly the kind of thing I like it for and why I hope we might be 
> able to keep scoped access even if it gets a new name that ends up as awkward 
> as fileprivate (allowing private to revert to the Swift 2 meaning).
> 
>> 
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

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. 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 only. No 
>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Eh, I've used `private` to keep myself honest in terms of going through some 
> book-keeping functions instead of directly accessing a property.

This is exactly the kind of thing I like it for and why I hope we might be able 
to keep scoped access even if it gets a new name that ends up as awkward as 
fileprivate (allowing private to revert to the Swift 2 meaning).

> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> 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 complications that 
> only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.

Eh, I've used `private` to keep myself honest in terms of going through some 
book-keeping functions instead of directly accessing a property.

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> 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 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 
 On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> 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 uses extensions pervasively.  Chris’s suggestion of having private 
> mean “same file *and* same type” would be a good default.  But if we’re 
> not willing to *also* have fileprivate then the Swift 2 definition of 
> private is the best “default’.  
> 
> I still think scoped access control is valuable but taking `private` as 
> the keyword for this was a mistake.  I’d like to see us take another stab 
> at identifying a suitable name for it.  That said, I get the feeling that 
> not too many others have appetite for this so it may be a lost cause…
 
 My opinion is that a file level grouping is fine, but that people want a 
 level between that and internal. They want to have subsystems. In Swift 2, 
 the only level below framework-wide was the fileprivate-style scope, which 
 had the potential to encourage lots of interrelated code to be grouped 
 within a single source file. 
>>> 
>>> Is it really necessary to encode this subsystem grouping in a way that can 
>>> be checked by the compiler though, instead of enforcing it with coding 
>>> conventions?
>>> 
>>> Slava
>> 
>> It’s also worth pointing out that private/fileprivate have been a constant 
>> source of implementation issues:
>> 
>> - They do not have a stable mangled name, and cannot be serialized in a 
>> meaningful way
>> - The ‘private descriminator’ adds complexity to serialization and mangling 
>> in general
> 
> This is confusing — in the first case I’m talking about serialization as in 
> NSCoding, in the second I’m referring to .swiftmodule file generation in the 
> compiler.

Oh and of course just the logic for the actual accessibility checking in Sema 
is a bit scary now. There were holes in the implementation in Swift 3, so now 
Swift 3.1 has to simulate the old quirks, but emit warnings in Swift 3 mode, 
and emit errors in Swift 4 mode.

Slava

> 
> Slava
> 
>> - Slightly different linking behavior in WMO and non-WMO builds
>> - Textual SIL cannot use them, which together with the above blocks the 
>> stdlib from adopting ‘private'
>> 
>> I’m sure there are others. There’s an opportunity cost to keeping quirky 
>> features around and adding new ones — it prevents us from being able to 
>> spend more time on improvements that actually matter, such as compile time, 
>> crashes and diagnostics.
>> 
>> Slava
>> 
>>> 
 
 -DW
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Feb 16, 2017, at 4:50 PM, Slava Pestov  wrote:
> 
>> 
>> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution 
 mailto:swift-evolution@swift.org>> 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 
 uses extensions pervasively.  Chris’s suggestion of having private mean 
 “same file *and* same type” would be a good default.  But if we’re not 
 willing to *also* have fileprivate then the Swift 2 definition of private 
 is the best “default’.  
 
 I still think scoped access control is valuable but taking `private` as 
 the keyword for this was a mistake.  I’d like to see us take another stab 
 at identifying a suitable name for it.  That said, I get the feeling that 
 not too many others have appetite for this so it may be a lost cause…
>>> 
>>> My opinion is that a file level grouping is fine, but that people want a 
>>> level between that and internal. They want to have subsystems. In Swift 2, 
>>> the only level below framework-wide was the fileprivate-style scope, which 
>>> had the potential to encourage lots of interrelated code to be grouped 
>>> within a single source file. 
>> 
>> Is it really necessary to encode this subsystem grouping in a way that can 
>> be checked by the compiler though, instead of enforcing it with coding 
>> conventions?
>> 
>> Slava
> 
> It’s also worth pointing out that private/fileprivate have been a constant 
> source of implementation issues:
> 
> - They do not have a stable mangled name, and cannot be serialized in a 
> meaningful way
> - The ‘private descriminator’ adds complexity to serialization and mangling 
> in general

This is confusing — in the first case I’m talking about serialization as in 
NSCoding, in the second I’m referring to .swiftmodule file generation in the 
compiler.

Slava

> - Slightly different linking behavior in WMO and non-WMO builds
> - Textual SIL cannot use them, which together with the above blocks the 
> stdlib from adopting ‘private'
> 
> I’m sure there are others. There’s an opportunity cost to keeping quirky 
> features around and adding new ones — it prevents us from being able to spend 
> more time on improvements that actually matter, such as compile time, crashes 
> and diagnostics.
> 
> Slava
> 
>> 
>>> 
>>> -DW
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 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 
>>> uses extensions pervasively.  Chris’s suggestion of having private mean 
>>> “same file *and* same type” would be a good default.  But if we’re not 
>>> willing to *also* have fileprivate then the Swift 2 definition of private 
>>> is the best “default’.  
>>> 
>>> I still think scoped access control is valuable but taking `private` as the 
>>> keyword for this was a mistake.  I’d like to see us take another stab at 
>>> identifying a suitable name for it.  That said, I get the feeling that not 
>>> too many others have appetite for this so it may be a lost cause…
>> 
>> My opinion is that a file level grouping is fine, but that people want a 
>> level between that and internal. They want to have subsystems. In Swift 2, 
>> the only level below framework-wide was the fileprivate-style scope, which 
>> had the potential to encourage lots of interrelated code to be grouped 
>> within a single source file. 
> 
> Is it really necessary to encode this subsystem grouping in a way that can be 
> checked by the compiler though, instead of enforcing it with coding 
> conventions?
> 
> Slava

It’s also worth pointing out that private/fileprivate have been a constant 
source of implementation issues:

- They do not have a stable mangled name, and cannot be serialized in a 
meaningful way
- The ‘private descriminator’ adds complexity to serialization and mangling in 
general
- Slightly different linking behavior in WMO and non-WMO builds
- Textual SIL cannot use them, which together with the above blocks the stdlib 
from adopting ‘private'

I’m sure there are others. There’s an opportunity cost to keeping quirky 
features around and adding new ones — it prevents us from being able to spend 
more time on improvements that actually matter, such as compile time, crashes 
and diagnostics.

Slava

> 
>> 
>> -DW
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> 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 
>> mailto:swift-evolution@swift.org>> 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 uses 
>> extensions pervasively.  Chris’s suggestion of having private mean “same 
>> file *and* same type” would be a good default.  But if we’re not willing to 
>> *also* have fileprivate then the Swift 2 definition of private is the best 
>> “default’.  
>> 
>> I still think scoped access control is valuable but taking `private` as the 
>> keyword for this was a mistake.  I’d like to see us take another stab at 
>> identifying a suitable name for it.  That said, I get the feeling that not 
>> too many others have appetite for this so it may be a lost cause…
> 
> My opinion is that a file level grouping is fine, but that people want a 
> level between that and internal. They want to have subsystems. In Swift 2, 
> the only level below framework-wide was the fileprivate-style scope, which 
> had the potential to encourage lots of interrelated code to be grouped within 
> a single source file. 

Is it really necessary to encode this subsystem grouping in a way that can be 
checked by the compiler though, instead of enforcing it with coding conventions?

Slava

> 
> -DW
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Arnold via swift-evolution]

Hi Matthew,

> On 17 Feb 2017, at 10:28, 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 uses 
> extensions pervasively.  Chris’s suggestion of having private mean “same file 
> *and* same type” would be a good default.  But if we’re not willing to *also* 
> have fileprivate then the Swift 2 definition of private is the best 
> “default’.  
> 
> I still think scoped access control is valuable but taking `private` as the 
> keyword for this was a mistake.  I’d like to see us take another stab at 
> identifying a suitable name for it.  That said, I get the feeling that not 
> too many others have appetite for this so it may be a lost cause…

I agree - I’d love to see the current list of controls refined. 

Personally, (and I understand that everyone has different needs) I see little 
point to `private` and `fileprivate` as they are implemented in Swift 3. If I 
have access to edit the source file of a class, what purpose does `private` in 
Swift 3 even serve? Documentation? Surely there are better ways to come at that 
issue? 

Similarly, `fileprivate` means I need to put my extensions in the same file as 
the original class, leading to unnecessarily large source files. 


My preference would be replacing `private` and `fileprivate` with “same file 
and same type” as you mentioned. Ultimately, most of my current use cases that 
would take advantage of this could be handled by splitting my code into 
separate frameworks and using `internal`.

Cheers,


Tony



--
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> 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 uses 
> extensions pervasively.  Chris’s suggestion of having private mean “same file 
> *and* same type” would be a good default.  But if we’re not willing to *also* 
> have fileprivate then the Swift 2 definition of private is the best 
> “default’.  
> 
> I still think scoped access control is valuable but taking `private` as the 
> keyword for this was a mistake.  I’d like to see us take another stab at 
> identifying a suitable name for it.  That said, I get the feeling that not 
> too many others have appetite for this so it may be a lost cause…

My opinion is that a file level grouping is fine, but that people want a level 
between that and internal. They want to have subsystems. In Swift 2, the only 
level below framework-wide was the fileprivate-style scope, which had the 
potential to encourage lots of interrelated code to be grouped within a single 
source file. 

-DW

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 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 
>> degree of the benefits of all these access levels is not as significant as 
>> it seems on the surface.
> 
> I think this applies more to private vs. fileprivate.  Having *some* way to 
> mark something as private — if nothing else, to tell other programmers 
> (including Future You) to think twice before using it directly — is pretty 
> useful in a large project.  But having finer shades than that does seem to 
> just cause mental anguish.

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 uses 
extensions pervasively.  Chris’s suggestion of having private mean “same file 
*and* same type” would be a good default.  But if we’re not willing to *also* 
have fileprivate then the Swift 2 definition of private is the best “default’.  

I still think scoped access control is valuable but taking `private` as the 
keyword for this was a mistake.  I’d like to see us take another stab at 
identifying a suitable name for it.  That said, I get the feeling that not too 
many others have appetite for this so it may be a lost cause...

> 
> John.
> 
>> 
>> l8r
>> Sean (who has no actual data)
>> 
>> 
>>> On Feb 16, 2017, at 4:34 PM, 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 complications that 
>>> only serve to clutter the language.
>>> 
>>> It would make a lot more sense to just have internal and public only. No 
>>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>>> 
>>> Slava
>>> 
 On Feb 15, 2017, at 7:40 AM, T.J. Usiyan via swift-evolution 
  wrote:
 
 "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 
  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 see two plausible meanings for private:
> 
> Private could mean either:
> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that 
> type that are in the current file.
> 
> I don’t think we’ve ever evaluated and debated approach #2 systematically.
 
 For what it's worth:
 
 I was opposed to SE-0025, but since I lost, I have tried to use `private` 
 wherever it made sense, rather than fighting with the language.
 
 Sometimes, the change of keyword makes no difference. Other times, it's a 
 hassle, because I have to switch between `private` and `fileprivate` as I 
 redesign things, with little perceived benefit. I'd say the split between 
 these is about 50/50.
 
 On a few occasions, I *have* genuinely appreciated the SE-0025 version of 
 `private`. These involved cases where I wanted to ensure that instance 
 variables were only manipulated in certain ways, using interfaces I had 
 specifically designed to handle them correctly. For instance, I might have 
 two parallel arrays, and I wanted to make sure that I only added or 
 removed elements from both arrays at once. I could do this with 
 `fileprivate` by splitting the type into two files, but it was more 
 convenient to do it in one.
 
 In these cases, switching to #2 would *completely* defeat the purpose of 
 using `private`, because the extensions would be able to directly 
 manipulate the private instance variables. I would no longer gain any 
 benefit at all from `private`. All of my uses would either fall into 
 "makes no difference" or "it's a hassle".
 
 I do not support the idea of changing `private` to mean #2. Doing so would 
 eliminate the few decent use cases I've found for `private`. Either keep 
 it or drop it, but don't keep fiddling with it.
 
 --
 Brent Royal-Gordon
 Architechies
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo

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

[David Waite via swift-evolution]

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 behavior 
(or even, start having the language itself enforce the naming conventions)

Our justification of access modifiers should be based around communication and 
compiler optimization, and not completeness against possible options or against 
features in other languages.

So private and fileprivate serve to communicate that something is an 
implementation detail of a type, and that manipulation without understanding 
the type could lead to you (for example) invalidating the type invariants. This 
IMHO is a useful enough concept to warrant a keyword to communicate.

However, my opinion is that it absolutely *doesn’t* warrant two keywords, and 
“private” is the less useful of the two due to it blocking extensions.

-DW


> On Feb 16, 2017, at 3:34 PM, 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 complications that 
> only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
> 
> Slava
> 
>> On Feb 15, 2017, at 7:40 AM, T.J. Usiyan via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> "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 
>> mailto:swift-evolution@swift.org>> wrote:
>> > On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution 
>> > mailto:swift-evolution@swift.org>> wrote:
>> >
>> > Keeping with the spirit of Swift and staying consistent with its design, I 
>> > see two plausible meanings for private:
>> >
>> > Private could mean either:
>> > 1) private to the file (Swift 2 semantics)
>> > 2) accessible only to the current type/scope and to extensions to that 
>> > type that are in the current file.
>> >
>> > I don’t think we’ve ever evaluated and debated approach #2 systematically.
>> 
>> For what it's worth:
>> 
>> I was opposed to SE-0025, but since I lost, I have tried to use `private` 
>> wherever it made sense, rather than fighting with the language.
>> 
>> Sometimes, the change of keyword makes no difference. Other times, it's a 
>> hassle, because I have to switch between `private` and `fileprivate` as I 
>> redesign things, with little perceived benefit. I'd say the split between 
>> these is about 50/50.
>> 
>> On a few occasions, I *have* genuinely appreciated the SE-0025 version of 
>> `private`. These involved cases where I wanted to ensure that instance 
>> variables were only manipulated in certain ways, using interfaces I had 
>> specifically designed to handle them correctly. For instance, I might have 
>> two parallel arrays, and I wanted to make sure that I only added or removed 
>> elements from both arrays at once. I could do this with `fileprivate` by 
>> splitting the type into two files, but it was more convenient to do it in 
>> one.
>> 
>> In these cases, switching to #2 would *completely* defeat the purpose of 
>> using `private`, because the extensions would be able to directly manipulate 
>> the private instance variables. I would no longer gain any benefit at all 
>> from `private`. All of my uses would either fall into "makes no difference" 
>> or "it's a hassle".
>> 
>> I do not support the idea of changing `private` to mean #2. Doing so would 
>> eliminate the few decent use cases I've found for `private`. Either keep it 
>> or drop it, but don't keep fiddling with it.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 think how much brainpower I’ve wasted(?) on 
> deciding which one to use when. I strongly suspect that the degree of the 
> benefits of all these access levels is not as significant as it seems on the 
> surface.

I think this applies more to private vs. fileprivate.  Having *some* way to 
mark something as private — if nothing else, to tell other programmers 
(including Future You) to think twice before using it directly — is pretty 
useful in a large project.  But having finer shades than that does seem to just 
cause mental anguish.

John.

> 
> l8r
> Sean (who has no actual data)
> 
> 
>> On Feb 16, 2017, at 4:34 PM, 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 complications that 
>> only serve to clutter the language.
>> 
>> It would make a lot more sense to just have internal and public only. No 
>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>> 
>> Slava
>> 
>>> On Feb 15, 2017, at 7:40 AM, T.J. Usiyan via swift-evolution 
>>>  wrote:
>>> 
>>> "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 
>>>  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 
 see two plausible meanings for private:
 
 Private could mean either:
 1) private to the file (Swift 2 semantics)
 2) accessible only to the current type/scope and to extensions to that 
 type that are in the current file.
 
 I don’t think we’ve ever evaluated and debated approach #2 systematically.
>>> 
>>> For what it's worth:
>>> 
>>> I was opposed to SE-0025, but since I lost, I have tried to use `private` 
>>> wherever it made sense, rather than fighting with the language.
>>> 
>>> Sometimes, the change of keyword makes no difference. Other times, it's a 
>>> hassle, because I have to switch between `private` and `fileprivate` as I 
>>> redesign things, with little perceived benefit. I'd say the split between 
>>> these is about 50/50.
>>> 
>>> On a few occasions, I *have* genuinely appreciated the SE-0025 version of 
>>> `private`. These involved cases where I wanted to ensure that instance 
>>> variables were only manipulated in certain ways, using interfaces I had 
>>> specifically designed to handle them correctly. For instance, I might have 
>>> two parallel arrays, and I wanted to make sure that I only added or removed 
>>> elements from both arrays at once. I could do this with `fileprivate` by 
>>> splitting the type into two files, but it was more convenient to do it in 
>>> one.
>>> 
>>> In these cases, switching to #2 would *completely* defeat the purpose of 
>>> using `private`, because the extensions would be able to directly 
>>> manipulate the private instance variables. I would no longer gain any 
>>> benefit at all from `private`. All of my uses would either fall into "makes 
>>> no difference" or "it's a hassle".
>>> 
>>> I do not support the idea of changing `private` to mean #2. Doing so would 
>>> eliminate the few decent use cases I've found for `private`. Either keep it 
>>> or drop it, but don't keep fiddling with it.
>>> 
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution