[swift-evolution] final + lazy + fileprivate modifiers

[Joanna Carter]

> Le 22 févr. 2017 à 01:19, David Waite <david at alkaline-solutions.com> 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