> 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

Reply via email to