> To summarize the place we’d like to end up:
>
> - “public” -> symbol visible outside the current module.
> - “internal” -> symbol visible within the current module.
> - unknown -> symbol visible within the current file.
> - “private” -> symbol visible within the current declaration (class,
> extension, etc).
domestic?
I'm not too thrilled to see the list extend to four words though. The more
visibility levels we have between public and private the more subtle the
difference and meaningless the choice of word. So I think I'll fall in the camp
of private(file)`.
Speaking of meaning though, there's one thing bothering me about altering the
meaning of `private` to mean what `local` meant in the Scoped Access Level
proposal.
The new `private` keyword will sometime mean file-private and sometime mean
declaration-private depending on where it is. That's because file-private and
declaration-private are the same thing for elements not part of a declaration.
With the `local` keyword, I'd have expected the compiler to emit an error for
this declaration found at the root of a file:
local class A {} // error: use `private` at file scope
thus, restricting `local` to where it actually had an effect: inside
declarations. It's useful when seeing `local` to know that this symbol will not
be accessible everywhere in the file.
But does this same restriction makes sense for `private`? I think not. And that
will make the `private` attribute have the same meaning as `private(file)` when
at the root of the file. I'm thus privileging `private(file)` because it makes
sense for the compiler to do this:
private(file) class A {} // error: use `private` at file scope
whereas using a different keyword would make things look messy. Note that I'm
reversing the error here: the compiler wants `private` (the old `local`) to be
used at file scope, and `private(file)` would be reserved for use inside
declarations.
Put simply: whatever the keyword we end up with, oftentimes it'll have the same
meaning as `private` and the compiler will have to force your hand with one or
the other. In my opinion the old approach with the `local` keyword was cleaner
because there was no overloaded meaning.
--
Michel Fortin
https://michelf.ca
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution