[swift-evolution] classprivate protection level?

Mike Kluev mike.kluev at gmail.com
Mon Oct 30 07:34:46 CDT 2017

On 30 October 2017 at 07:30, Adam Kemp <adam.kemp at apple.com> wrote:

> No. There are two reasonable options:
> 1. Make it public. If it’s needed outside the module then this is an
> accurate description of its access level.
> 2. Make it internal and accept that any code in the same module can access
> it. Again, that is effectively what your proposed scope allows anyway so
> internal is an accurate description of its actual access level. Call it
> what it is.
Adam, i fail to see why you say "No" to "one module per class approach" if
the goal is to make the individual multi-file classes as isolated as
possible (i.e. not see each other "internal" stuff). which (this goal) is
considered the "way to go" approach in other languages and the "default"


SingleFileClass1.swift // with bunch of "privates" inside

SingleFileClass2.swift // with bunch of "privates" inside

SingleFileClass3.swift // with bunch of "privates" inside

is equivalent to this:

Module solely for Class1
   Class1.swift // with bunch of "internals inside
   Class1+Extension.swift // with bunch of "internals" inside

Module solely for Class2
   Class2.swift // with bunch of "internals" inside
   Class2+Extension.swift // with bunch of "internals" inside

Module solely for Class3
   Class3.swift  // with bunch of "internals" inside
   Class3+Extension.swift // with bunch of "internals" inside

still "no" ?

i mean, it's fine (although a bit odd) that a mere change from a
single-file to a multi-file class leads to such drastic consequences.
different to what i saw before. but I can adapt of course.

Either way the answer is basically the same: don’t obfuscate the effective
> access level and pretend you’re being strict when you’re really not. It’s
> like putting a lock on the door with the key hanging from the doorknob. You
> may as well just keep it unlocked.
nice analogy :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171030/89a2bbc5/attachment.html>

More information about the swift-evolution mailing list