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

[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]

I'm still in favor of protectedinternal.

[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.

[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.

[gafter]

@Stevie-O Too late, sorry. This is already in C# 7.2.

We had a large discussion about the syntax in the C# 6.0 timeframe, and the community was much more upset by the fact that we pulled the feature because of the discussion than about any particular proposed syntax. The syntax issue was solved in C++, where private protected has been available for years.

Yes, the feature is useful. Just like private is useful, even though you could get away without it just by asking your developers to apply some self-control and spend more time reading documentation. We like to save programmer time by automating such things.

[HaloFour]

@paulomorgado

Yeah, it has been debated enough. The team should either execute or drop.

This is a feature with such a limited use case that it doesn't deserve the kind of debate that it's already received. It doesn't solve any problems. It's at most a tool to help developers not use their own source incorrectly.

And protectedinternal is awful. Not everyone uses monospace fonts and that whitespace will be totally lost, assuming someone doesn't fat-finger and mess it up to begin with.

[alrz]

Head meets desk.

[HaloFour]

@hardhub

Why not? Holy Grail for MS?

Microsoft has existing customers with existing codebases. Unlike some companies, Microsoft prefers to not break all of their stuff on a semi-annual basis. Maintaining backward compatibility is critically important.

Sometimes to do something better we have to think again.

This will be version 8.x, not version 1.x. It's not going to be thought over. Existing syntax is off of the table. Breaking changes are off of the table.

There is best practice... It is absolutely normal when developer uses the same modifiers order in all cases.

Irrelevant. The keywords are perfectly legal in any order. Microsoft has no established "best practices" guidelines on the ordering of those keywords. JetBrains doesn't get to decide any "best practices" either for everyone either. A common convention is not "best practice".

Then nothing, because it is very uninformative and unnatural...

That's your opinion. C++ already went with private and protected and the world didn't end.

I personally think that small breaking change is better than "private protected" and I explained it enough above.

A breaking change is a deal breaker. The team has also already decided that alternative syntax is off of the table.

[jnm2]

Just no.

@HaloFour

Microsoft has existing customers with existing codebases. Unlike some companies, Microsoft prefers to not break all of their stuff on a semi-annual basis. Maintaining backward compatibility is critically important.

Yeah really? Where is Flash-killer? Maybe ASP.Net Core is the same as ASP.Net? Or maybe we did not changed VS from and to msbuild (twice) during last 2 years?
RedHat also supports enterprises but sometimes after many years of LTS they can improve something with not critical but breaking changes.
I just want to say we have what we have: MS does not want any breaking changes in C#... But please do not insist that it is single way to go.

This will be version 8.x, not version 1.x. It's not going to be thought over. Existing syntax is off of the table. Breaking changes are off of the table.

Not sure that I understand.. but if I understand it correctly.. it will mean slowing down of C# evolution after some time because we cannot change what is already made even it is very appreciated.

Irrelevant. The keywords are perfectly legal in any order. Microsoft has no established "best practices".

Hmm... Relevant! (I am also able to say something without any arguments).
Where is I said it is illegal? Maybe when I said that A and B are allowed?
Or maybe it is just the problem with MS? MS can but JetBrains cannot? Fair play ))
Wake up man, it is already in wide open source community.

JetBrains doesn't get to decide any "best practices" either for everyone either. A common convention is not "best practice".

It is already so... Just read all their rules... Many of them is really very very apreciated.
And for many developers ReSharper becomes tool "must have". And it was mentioned just FYI. So many developers always use "protected internal". Also many books about C# teach developers using "protected internal" in examples, not "internal protected" (even if both allowed as I wrote previously).
If you want to understand how much projects will be impacted you can estimate it using search over GitHub open projects codebase.

C++ already went with private and protected and the world didn't end.

Who of us is crazy? Where did you found "private protected" access modifier in C++?
You mixed up the terms.

A breaking change is a deal breaker. The team has also already decided that alternative syntax is off of the table.

I think I wrote enough about breaking changes.
I think if it will be very required the community will fork and create C# Next v1.0...
Where evolution will be more important than any deals...

P.S. If you do not have really new information and arguments then we do not need to continue this discussion to avoid wasting of time.

[jnm2]

private protected makes enough sense. It's fine that it isn't purely etymologically consistent. No one thinks through the logic anyhow; it's just a convention we've memorized. Also, subjectively, private protected is the least awkward sounding name I've heard so far.

[HaloFour]

Yes breaking change, but not serious.

It's a breaking change, end of story. That makes it a non-starter.

So we can hope that developers use best practices... and used "protected internal".

There is no "best practice" there. The order of the keywords is entirely up to the developer.

As mentioned above, it's private protected (and protected private) or nothing. The arguing over other keywords is done.

@HaloFour

It's a breaking change, end of story. That makes it a non-starter.

Why not? Holy Grail for MS?
Sometimes to do something better we have to think again.

There is no "best practice" there. The order of the keywords is entirely up to the developer.

There is best practice... It is absolutely normal when developer uses the same modifiers order in all cases.
And it is exactly what "best practice" definition means.. If we allowed to do A and B but we decided that it is better to always do A then A is best practice.. And I believe that mostly all developers use protected internal.

it's private protected (and protected private) or nothing

Then nothing, because it is very uninformative and unnatural... protected and internal are not exclusive terms... but private and protected are... and if member can be protected and internal at the same time it is OK, but it is not true for private and protected (and even more ridiculous way: protected private)... So the cognitive dissonance is welcome!

So... in other words... I personally think that small breaking change is better than "private protected" and I explained it enough above.

[tannergooding]

@paulomorgado, having a language construct that is created from multiple keywords is not that unusual. In some cases, like C++ they separate the words with underscore (thread_local for example). The use case here is potentially small, and the way it is constructed makes sense and will be familiar to anyone who has declared similar types before (such as in C++/CLI).

[gafter]

Unfortunately all of the options other (other than private protected) are quite expensive or irregular, for example introducing new keywords (a breaking change) or adding operator characters such as & to the modifiers, or making the modifiers order-sensitive.

[axel-habermaier]

@hardhub: At this point I think it is pretty clear that the feature either comes as private protected, or not at all. protected & internal or protected | internal have already been suggested in addition to countless other things. There simply is no good alternative. See also the old Codeplex thread.

Additionally, protected internal and internal protected already mean the same thing today, so changing the meaning of one of them would be a serious breaking change which is also not going to happen.

[HaloFour]

MS does not want any breaking changes in C#.

The team has stated this multiple times. Proposals that suggest redefining existing syntax in a way that changes the behavior of existing code is nearly immediately shot down. A proposal has to demonstrate massive benefit to consider even slight syntactic breaks, and even then only if that potential break would only affect esoteric code.

Hmm... Relevant! (I am also able to say something without any arguments).
Where is I said it is illegal? Maybe when I said that A and B are allowed?

There is no argument. All of the modifiers can be applied in any order. protected static internal async is just as valid as async internal static protected. Preferring one order over another doesn't justify changing the behavior due to reordering.

Who of us is crazy? Where did you found "private protected" access modifier in C++?
You mixed up the terms.

Applies to C++/CLI:

https://msdn.microsoft.com/en-us/library/ke3a209d.aspx#BKMK_Member_visibility

If you do not have really new information and arguments then we do not need to continue this discussion to avoid wasting of time.

I agree. The team already weighed in on whether or not alternate would be considered. Breaking change or not, they're not interested.

[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.

[alrz]

@paulomorgado internally protected.

[paulomorgado]

@axel-habermaier, looks like it hasn't been debated long enough.

Any outcome that is not a single keyword is not a cure. It's just a Band-Aid that we'll have to live with forever.

[alrz]

__arglist, __refvalue, __makeref, __reftype for one.

language construct in C# uses more than one keyword?

yield return or all other modifiers?

[Athari]

I wonder why it's private protected and not private internal. What makes protected part of protected-and-internal more important than internal part?

I'd rather have something messy like protected&internal and protected|internal (with protected internal left for compatibility) than a combination of keywords that leaves out 50% of information it needs to convey. 😕

[DavidArno]

When the team decided so. At this point it's private protected or not at all.

Does that mean "not at all" is still an option? 😇

@axel-habermaier

Codeplex

It was time when it was looking very bad to have it that way...
And I do not strongly suggest it because I also do not expect anything except English alphabet there.
But maybe for now it is smallest of all evils? If you think it is still bad.. I can agree but what is good alternative? I am sure it is not 'private protected'!

would be a serious breaking change

Yes breaking change, but not serious.
Consider that ReSharper always suggests it to be as protected internal:
https://www.jetbrains.com/help/resharper/2017.1/ArrangeModifiersOrder.html
Many things in ReSharper is bad but many things including this one are really good!
So we can hope that developers use best practices... and used "protected internal".

But let's consider worst case.. If you not followed such rule you will need only to replace simple text string with Ctrl+Shift+H in VS or any other text editor.
If you did not make that I guess you will not be able to compile code due to access level.. so you will finally replace it.

[DavidArno]

As I see it the logic behind this proposal is that folk want to use inheritance as an "implementation detail", ie exposing certain methods to sub classes, but only when those sub classes are defined in the same assembly. Now "internally protected" methods are one way of achieving that, thus this proposal. However, there is an alternative way, that would have added benefits: publicly sealed classes.

For some type, let's assume the syntax is:

public abstract sealed SomeClass { ...

That class is then unsealed within its assembly, so can be extended and its protected methods accessed. Outside that assembly though, the class is sealed. This idea would address (most of, at least) the use-cases for private protected. It would also provide an immediate means of creating finite type hierarchies and would lay the groundwork for supporting discriminated union types in a future version.

This would require a CLR change, but as that team will be making changes to support trait interfaces, this change could be made at the same time.

[tannergooding]

Breaking changes, of any kind, all start in the same bucket: "no". It takes a very significant issue (or benefit) to change this.

C# has been around for 17 years, across 7 language versions, and is used by millions of developers around the world. A very large portion of this is closed source enterprise code that we will never be able to look at. This means we have no way of knowing if they follow "common practice" or if a breaking change will or will not impact them.

There are a couple different types of breaking-changes (this is a non-exhaustive list):

• Those that impact binaries that have already been built/shipped. This means that if the change was taken, it could impact code that has already been compiled and has been shipped for public use. The producer of the binary does nothing and things break, this is potentially the worst type of change.
• Those that impact existing source code. These changes will change what a users code is doing if they take it and recompile it with the new compiler (things like making the ordering of visibility modifiers relevant fall into this category). This is likely the second worst type of change, users compile their code and it now behaves differently. It can potentially impact any downstream consumers of the newly built library and the library itself.

The primary thing to take into consideration when talking about a breaking change is how much code it could potentially impact. For something that has been around since v1.0 of the compiler, it is 17 years worth of code that could be impacted. For something like accessibility modifiers, which are used everywhere, it also has a high risk of impacting some code somewhere.

If we assume that C# has at least 1 million users (recent Stack Overflow surveys indicate that it is much more than this), and we look at a change will only impact 1% of users, we are still looking at potentially breaking at least 10,000 users, which is a lot.

Every feature request (breaking change or not) has to be weighed on impact. If it is only going to benefit or be used by a couple hundred developers, it might not be worth it. If it is going to be used by a relatively small portion of users, then will the resulting code in turn be used by others? For example, there are a lot of unsafe or interop features which will be consumed by a relatively small portion of users, but it will allow them to more readily write libraries that will, in turn, be used by hundreds or thousands of other developers (things like blittable types fall into this category).

[Stevie-O]

I may be a bit late to all this, but I'm not sure I quite see this feature being particularly beneficial.

As I understand it, the goal is to add syntax to C# for the CLR's built-in famandassem accessibility mode, where the class member is only accessible to (1) members inside the declaring class, and (2) members inside a descendant class, iff that descendant class is also defined in the same assembly as the declaring class.

We can't use internal protected or protected internal because today, both of those things mean famorassem -- i.e. accessible to (1) members inside the same assembly as the declaring class, and (2) members inside a descendant class.

As far as I can tell, the only benefit this offers over 'internal' is as follows: Someone writing code in your assembly can't call your method (or access your field/property, or hook your event) unless they also inherited from your class.

Is there really that large a demand for this? If I were writing a method that required the constraints of famandassem, I would just mark it internal and clearly document for my fellow developers how it's intended to be used. If I'm really paranoid, I can just start the method with Debug.Assert(this is MyType); and let it be caught in testing. But before all that, I would seriously consider whether or not it was truly appropriate to restrict access that way.

I could see this feature being useful if:
(1) There was a major use case that could not be solved without this functionality (despite not having had it for over 12 years)
(2) We could come to an agreement on syntax we liked

But we don't seem to have either of these things. And if I were the one making the call, I would hold off on until we had at one of these two things.

[gafter]

@DavidArno We are not pursuing any of the gyrations you suggest regarding protection in the traits proposal.

[CyrusNajmabadi]

Roslyn already has code that uses "internal protected". Changing of the meaning of that could literally make the existing Roslyn codebase uncompilable by later versions of the compiler.

[Adassko]

Why not just combine all three and name it "protected internal private"?
It makes more sense for me as it's more "internal" than "private"

[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.

[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.

[axel-habermaier]

@paulomorgado: This has been debated over and over again. There is no good solution. It's either private protected or we'll never get the feature. I'm not happy with private protected either, but I also don't have a better solution. So let's just live with that and let's get that feature into the language!

[paulomorgado]

@tannergooding,

What other keyword in C# uses underscore?

What other language construct in C# uses more than one keyword?

[tannergooding]

using static as well

[bbarry]

I'd say async/await is a single language construct that uses more than one keyword to express.

[alrz]

@bbarry Actually wait for was also considered before await just that it did not require async.

[paulomorgado]

I knew that, if gave enough rope, plenty would jump to wrap it around their necks. 😄

__arglist, __refvalue, __makeref, `__reftype

These keywords are not on the list of the C# keywords on the documentation or the C# Language Specification. If the recommendation is for this feature to be tuck away hidden from the non illuminati, then, by all means, __protected_internal.

yield return

I would argue that yield is one thing and return and break another. But, yes, they are the Yield Statements, not the Yield Statement.

other modifiers

Which ones? Are you counting protected internal and internal protected as two. Or are you saying that abstract, virtual, abstract, override or async are access modifiers?

using static

I would argue that static is part of the argument of the using directive which is a one keyword only construct. Just that until now there was no need for using namespace ... and using alias .....

async/await

Hardly. I can use async without any await, although I can only use one or more awaits with one async.

In any case, async is a method modifier and await is, like yield, some sort of statement modifier.

[jnm2]

-_-

[Athari]

@alrz What?

I know I'm late to the party. Like, 3 years late or so. But I still find private protected FUBAR.

[jnm2]

@Athari #37 (comment) Also, people are incredibly tired of the argument. Perpetuating the argument has prevented and will continue to prevent this useful feature from appearing in any form.

[Athari]

@jnm2 When did private protected win, by the way? It lost badly in the poll on CodePlex. Just because of C++/CLI?

[HaloFour]

@Athari

When the team decided so. At this point it's private protected or not at all.

[GeirGrusom]

Does that mean "not at all" is still an option? 😇

It's ridiculous that a useful feature should be dropped because people get caught up in unimportant superficial issues like this. It's private protected. Now come to terms with that and simply move on.

[DavidArno]

@GeirGrusom,

You misunderstand. For me, this is a worthless feature. I don't care what it's called; I have zero use for it. Thus why I was asking whether "not at all" was still an option. I'd prefer the team focused on things that are useful to me... 😀

[alrz]

This will be useful with other concepts like exhaustiveness,. Records and ADTs could take advantage of it, maybe.

[DavidArno]

@alrz,

Hmm, that's a good point: the choice of keywords used here could adversely affect the trait interface proposal. For example, an internal member in a public interface could mean "only internal types can access this member" or "only internal types can implement this interface" (the latter being incredibly useful for ADTs). private internal could be used to indicate one of those options and internal, the other. Likewise, if the team go down the route of a public method in a class can implement/override a protected member in an interface, then private protected could be used to mandate that the implementation must be protected.

So I think the team should delay this feature until trait interfaces are properly worked out to avoid causing themselves problems later.

[tannergooding]

@gafter, even if you aren't pursuing it today, some future version of the language (even 5-10 years down the line) might want to pursue it (see IntPtr operators). So, I think the ask here is to ensure that being unable to (easily) support such a feature in the future is definitely the decision that wants to be made.

[gafter]

@tannergooding Overrides in interfaces already have nearly exact analogs to the hypothetical situations with interfaces, and never has anything like that been proposed. I don't think it is reasonable to "preserve" this particular sequence of keywords for such a hypothetical future language feature. We do not permit an override method in a class to have different access than the method it overrides, and I do not believe (if we even allow implicit overrides in interfaces) that we would want to change that in interfaces.

[DavidArno]

@gafter

We are not pursuing any of the gyrations you suggest regarding protection in the traits proposal.

So the discussions between yourself and Cyrus around this comment in the default methods thread came to nothing then? Perhaps I was very clear in what I said above, but I was referring to ideas discussed in that other thread and so I'm surprised you now claim all that has been cast aside.

[CyrusNajmabadi]

@DavidArno Sorry, i'm a bit lost. What are you trying to say?

[DavidArno]

@CyrusNajmabadi,

You are not the only one that's lost.

Here, @gafter states:

We can model this with the "required" methods being protected abstract, and the "provided" methods being public. ... This is not esoteric, but central to one of the use cases for the feature

Three comments above this one, he states:

We do not permit an override method in a class to have different access than the method it overrides, and I do not believe (if we even allow implicit overrides in interfaces) that we would want to change that in interfaces

Any idea which one if correct (or in what way they are not equivalent), as I'm really quite lost.

[gafter]

@DavidArno I think you misread that thread. "provided" in that thread means methods provided to clients (users) of the interface deeper in the hierarcy. "required" means methods that an interface's clients (users) must implement deeper in the hierarchy. Think of them like arguments (required) and returns (provided) of a trait. A given method is either one or the other.

[gafter]

@DavidArno Please make a separate proposal for that. This issue is about providing a syntax for a protection level that is already supported in the CLR and in other languages.

I think protected internal modifier has powerless syntax. We cannot cover all possible variants...
With this new modifier you want to add one additional trick... So syntax is still powerless and this new modifier is still something not clear and universal. I personally can even say it is ridiculous because considering "protected internal" behavior "private protected" modifier should be a union of private and protected which obviously does not make any sense.

So can we introduce order here?
Let's say protected internal and internal protected are different things?

protected internal means major protection is protected (on 1st place), so internal (on 2nd place) cannot change availability in another assembly. It means it will work like it is now.

internal protected means major protection is internal (on 1st place), so protected (on 2nd place) cannot change availability in another assembly. It means that it will be available only internally being protected.

Does it make any sense?

Alternatively to make it relatively universal we have to allow minimal boolean operators on modifiers.

protected & internal
protected | internal

Preferring one order over another doesn't justify changing the behavior due to reordering.

Why do you try to tell it again again and again? I know that.. but it does not mean that de-facto developers always sort modifiers in some specific way. But as I said to estimate real situation we can create crawler and check open sourced projects for any impact. Since we have confirmed that breaking changes is not the way we can forget about that.

Applies to C++/CLI:

When somebody tells about "C++" I imagine the following standards: C++98, C++03, C++11, C++14, C++17 but not Managed C++ (C++/CLI). So for now it is clear what you mean... But this managed C++ is designed by MS in parallel to C# and cannot be considered as some independent design. In other words if they chose wrong name and conception then it means they can do the same mistake for C#:

From MSDN:
private protected: Member is protected inside the assembly but private outside the assembly.
They called a camel a "bear kangaroo" or "kangaroo bear"! Nice ))

@tannergooding

I agree except 2 things:

Those that impact binaries that have already been built/shipped.

If we are talking about changes to modifiers then it will not be necessary. CLR supports all possible modifiers. Binaries will not be impacted at all.. all binaries should work. Except maybe reflection in very specific case. But in that specific case it will not work for ANY new modifier as well (including one discussing in this issue).

Those that impact existing source code.

Yes this will impact... But why not move this issue to new major release and create migration guide?
It is very strange that they abandoned msbuild then returned it back... We had around 50 projects migrated to project.json... and now back... They abandoned Silverlight in all major browsers when official support claimed till 2021... But they did that... they did not update SL plugin considering new plugin model in browsers. To be supported by all major browsers we had to rewrite all in frontend...
But to fix access modifier we just need 5-10 mins to use Replace All. It is not comparable impact!

Alternatively let's start new generation of C#... It was absolutely possible to create new .Net Core. Why not C#!? We even can introduce build levels depending on language version and still have enough compatibility...
But all that is not our topic I think... So just to summarize regarding current issue I will repeat myself: private protected is worst name ever used/suggested for that access modifier.
I think we should not repeat Managed C++ implementation and since it is dead I even do not see any reason to do that.

[tannergooding]

Alternatively let's start new generation of C#

This sounds like something that should go into a new issue 😉

It was absolutely possible to create new .Net Core

It's true that .NET Core is "new" and "different", but that is mostly just in some Desktop APIs not being available. Everything else is essentially compatible and changes made to .NET Core should get ported back to desktop eventually. It isn't like we went and fixed all the API issues that exist in the Desktop framework when .NET Core was created...

private protected is worst name ever used/suggested for that access modifier.

You aren't the only one that feels this way, but I believe the actual language team has already decided on this (coming from re-skimming the comments made so far). If you really feel that strongly, the source for the compiler is open and you are more than welcome to fork the repository and "fix" this in your cop (and maintain the change through future updates to the primary repo so you get other new language features as well).

[gafter]

Spec in progress at dotnet/csharpstandard#215