Champion "Private protected" (C# 7.2, VB 15.5)

[MadsTorgersen]

• Proposal added: proposals/private-protected.md
• Discussed in LDM (2015-09-08)
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

[paulomorgado]

I'm still in favor of protectedinternal.

[gafter]

@paulomorgado Do you know why this feature didn't make it into C# 6?

[alrz]

Do you know why this feature didn't make it into C# 6?

The syntax was not good enough? 😁

[paulomorgado]

You know I do, @gafter! 😄

To me, protected internal says that it's protected or any derived class internal. Meaning it is accessible to any derived class or any type in the same assembly.

protectedinternal says to me protected and internal. Meaning it is accessible to any derived class in the same assembly.

protectedinternal wouldn't be the first multi word keyword.

Any other proposal either doesn't look like anything seen in C# in the last 15+ years or builds on top of not using protectedinternal introducing different ways to do the same thing.

[HaloFour]

Oh not this again. protectedinternal suffers from the problem of being excessively long and not different enough (not everyone uses monospace fonts in their IDEs). My opinion is that the team should just go with private protected or whatever combination of keywords they want and ignore the 500 other options that aren't any better. I'm fine with private protected. C++/CLI already uses it for this very accessibility modifier.

[alrz]

In fact, I think protectedinternal is even more confusing as it's only different in a single whitespace. Also, the fact that private protected doesn't need syntax changes, makes it more preferable IMO.

[marek-safar]

If there is planned work in this area I'd like to see also introduction of private internal to control if internal types/members are affected by InternalsVisibleTo.

The idea is to use private internal if you don't want your internal types/members be visible outside of an assembly when InternalsVisibleTo is used.

[Joe4evr]

Does the CLR even support such a scenario, or does such a hypothetical private internal maybe not need CLR support?

[marek-safar]

@JOE4EVER This is pure language feature, no CLR involvement

[HaloFour]

@marek-safar

IIRC, using private internal as you suggested would require CLR changes as how InternalsVisibleToAttribute works is governed by the CLR.

And it should be a separate proposal.

[gafter]

Just to be clear everybody, the precise syntax had been debated ad nauseum a few years ago and this is the winner. If we do the feature the syntax will be private protected. If the community really hates that then we simply won't do the feature.

[paulomorgado]

@gafter,

Just to be clear everybody, the precise syntax had been debated ad nauseum a few years ago and this is the winner. If we do the feature the syntax will be private protected. If the community really hates that then we simply won't do the feature.

That has defeat written al over it.

Currently, access modifiers worked as a union. When more than one is allowed, each one retains the same semantics. If something is protected it doesn't change its "protectiveness" by adding or removing the internal modifier. That doesn't happen with the proposed solution.

I "hate" it because it hinders the learning of the language and the understanding of the code.

I know my proposal has a drawback that, regardless of the font used, an acidental removal or insertion of a white space will change the meaning of the program.

And I don't care that C++/CLI made the same mistake.

At this point I would prefer some new keyword like shielded or sheltered.