On 26 March 2025 00:22:47 GMT, Rob Landers <rob@bottled.codes> wrote:
>
>To be clear, I'm not trying to be difficult. As you mentioned, these were all
>things I had to think about for nested classes too. I know how nested classes
>work and why. How file-private would work, on the other hand, I have put
>little thought into. You say it is obvious (to paraphrase), but the devil is
>in the details, and there isn't much prior-art to draw from here either.
I think in some ways this is similar to the discussion I had with Edmond on the
async thread - my starting assumption is that new features should be consistent
with existing ones, unless there's a good reason to make an exception.
For instance, the language has various built-in types, so if we add a new type,
I would assume it will work in all the places that other types work. It might
be useful to ask questions like "does it need any special handling as a return
type?" but the answer will nearly always be "no". Asking "what behaviour should
it have as a return type?" is only necessary if you've answered "yes" to the
simpler question.
Similarly, the language has three built-in access levels, so if we add a new
one, I would assume it will work in all the same places, unless there's some
specific reason to add a special case.
>I agree, but these are all things we'd have to consider. I, personally, would
>consider it working the other way around. A trait declaring fileprivate would
>only be accessible in the trait; otherwise you would have to explain how
>fileprivate works without saying "the file it is written in" and in a way that
>is easy to understand -- for the RFC + docs. I don't know if it would be
>useless or useful though.
Just to be clear, my description is just how traits work today. The phrase
"compiler-assisted copy-and-paste" is widely used; I thought it was in the
manual, but can't see it at a glance. As soon as you talk about "inheriting
from traits", you're going to be on the wrong track.
Following the reasoning above, my thought process goes like this:
1) What does "private" mean in a trait?
It means "copy this property / method with a private modifier by default".
Access is granted to all code in the target class, not just other code in the
trait.
2) Can that apply to the proposed description of "fileprivate"/"samefile"?
Yes.
3) Is there a good reason to change that meaning and make the new feature
inconsistent?
I don't think so.
Any change would mean changing the description of traits (they would no longer
just be copied and pasted code), and would lead to additional questions (e.g.
what happens when the target class changes the visibility with an "as" clause?).
Any inconsistent behaviour should have to clear a high bar.
Rowan Tommins
[IMSoP]
