On 26 March 2025 00:22:47 GMT, Rob Landers <[email protected]> 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]