[swift-evolution] [Draft] Fix Private Access Levels

[Vladimir.S]

On 22.02.2017 11:26, Jonathan Hull via swift-evolution wrote:
>
>> On Feb 21, 2017, at 11:47 PM, David Hart <david at hartbit.com> wrote:
>>
>>
>>
>>> On 22 Feb 2017, at 08:37, Jonathan Hull <jhull at gbis.com> wrote:
>>>
>>> I fully agree. I actually think that applies to both solutions
>>> though.  As much as I would like to see the mess around private
>>> fixed, I think it needs to be as part of a well considered redesign
>>> of the access system that adds enough functionality to stop this
>>> cycle.  We can’t just rename things or flip back and forth between
>>> options every 6 months.
>>>
>>> As an example of what I think *is* an appropriate change is Nevin’s
>>> suggestion on another thread to add a single level of submodules
>>> (which group files).  As part of this change, ‘private’ would mean
>>> private to the submodule (or file if the file is not part of a
>>> submodule). Internal/Public/Open would remain unchanged.  Thus you
>>> have only private, internal, and public/open… but the fix came as
>>> part of unifying with other improvements (and is not just returning
>>> to pre-0025).
>>
>> I saw this but it looks very confusing for me: private would mean
>> different things in different contexts and I would have no way to make
>> things private to a file in a submodule.
>
> Nor would you have a way to make things private to a particular scope.
> Private would always mean private to the submodule (and files without an
> explicit submodule would be an implicit anonymous submodule). I like the
> simplicity.  You can basically think of it as Swift 2 private, but with
> the allowance to split things up into multiple files.
>
> Anyway, my main point (regardless of what people think of that
> particular proposal) is that we need to fix the underlying issues with
> access (not just rehash 0025).

Yes, I believe we all(most of us) agree "we need to fix", but in different 
ways.
And while one thinks of 'simplicity' as more easy way to *write* the 
code(don't need to think about access levels), other thinks as more easy 
way to *use* and *support* code(own or other's), when you can attentively 
configure access levels and get help from compiler in case one (even by 
mistake) is touching what was *not designed* to be touched.

 From my point of view the "underlying issues with access" is that we have 
no well-designed scoped access modifiers in addition to module/file access 
levels. I do think they are two axis of the access control/documentation, 
and should work together to aim the better code quality and 'simplicity' in 
all meanings.

The one way I can think of scoped access modifiers is that they should have 
explicit and clear naming, even if this will lead to more massive syntax 
(like Matthew Johnson suggested scoped(scopeName)). While keep 
public/internal/private(as was in Swift2) names simple and easy to use.

for example,
// File.swift
class C {
	scoped(type) var veryPrivateProp1 = 1
	public scoped(type:set) var veryPrivateProp2 = 2
	scoped(subtype) var akaProtectedProp3 = 3
	scoped(extension) var accessFromSubtypeAndExtension = 4

	// as it is common to give access to internals inside the same
	// file, IMO we need also this:
	scoped(file,subtype) var insideThisFileAndSubtypes = 5
	scoped(file,extension) var insideThisFileAndSubtypeAndExtension = 6
	
	// as a variant, currently "friend" means any code inside the file:
	//scoped(friend,subtype) ...
	//scoped(friend,extension) ...

	// ex: property, that can be changed only inside this type or 	
	// subtype, but can be accessed from extensions and inside this
	// file
	scoped(file,extensions) scoped(type,subtype:set) var myProp = 7
}

Just as the "food for thoughts"..

>
> Thanks, Jon
>
>>> Thanks, Jon
>>>
>>>> On Feb 21, 2017, at 2:41 PM, Xiaodi Wu via swift-evolution
>>>> <swift-evolution at swift.org> wrote:
>>>>
>>>> Well-written as-is.
>>>>
>>>> Overall, my feedback is that solution 2 should not be on the table
>>>> (though there are people who clamor for it), and not because I
>>>> don't agree with it. However, simply as a matter of following an
>>>> appropriate process, solution 2 was originally proposed in
>>>> SE-0025, fully considered, and modified by the core team to the
>>>> current design. One can disagree whether `scoped` is more
>>>> appropriate than `private` as a name for that access modifier, and
>>>> one is likely to say that `private` looks nicer than
>>>> `fileprivate`, but that's neither here nor there. The
>>>> appropriateness or niceness of these terms is unchanged from last
>>>> year. Re-submitting SE-0025 cannot be the solution for fixing
>>>> SE-0025.
>>>
>>
>>
>
> _______________________________________________ swift-evolution mailing
> list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>