private:
UPROPERTY(VisibleAnywhere, BlueprintReadOnly, meta = (AllowPrivateAccess = "true"))
bla bla bla
This kind of code makes just no sense to me.
Why would I think:
“I want the inheritor of this class allow access to this, so… I’ll put it into the private area and use a hack macro to allow access to it.”
Why?
It makes sense in the way Blueprint works with C++.
In order to use the BlueprintReadOnly node you have to make a Blueprint class that inherit from the C++ class. Therefore the Blueprint class can’t access any of the C++ private properties without the “hack” of AllowPrivateAccess.
If you make the Property Protected or Public blueprint can again access it but then you also give any C++ classes access to a property you wanted to keep private.
I only looked at such code so far or copied it. Not good enough to use it creatively.
But I NEVER saw any code in UE where it made sense to put it into the private area.
If even a blueprint is allowed to access it, why would I say:
“I have no idea what kind of other classes me or others will derive from this one in the future but this data must not be allowed to be accessed by these classes!”
It seems to me, people don’t understand the access specifiers. Sorry.
I have seen people put things into the private area per default.
Just… because it should not be public. And then they put member VARIABLES into the public area.
It is … weird.
Sometimes I am not sure if I am missing something completely or if 74.3% of the c++ programmers have no idea why they should use private/protected/public, so they just put it somewhere. And if that somewhere happens to be private, yeah… bad luck, then we need a hack.
I mean… it is not complicated.
And it has been YEARS seen I have seen code where it made sense to have variables with the private access specifier.
It is useful for that specific purpose of allowing Blueprint inherited functions to Read it without exposing it in C++.
Then put it into the protected area and use
UPROPERTY(BlueprintReadOnly)
?
No, then you exposed it to C++ Inherited classes AND you made it writable in C++ inherited classes.
Yes?
So?
I am pretty obnoxious currently, I know that, but please - if you are in the mood - keep coming 
Can you give me an example, where it is ok for a blueprint to read data X, but it must be totally impossible for each and every derived class to modify that data?
I mean… we are not talking about a security mechanism for nuclear rockets here.
We are talking about classes that are forbidden to use the data of their base class, even when they “ARE” that same thing?
If I derive a class D from a class B then the class D IS a class B. So why should it not be allowed to access that data?
Yes, there are cases. And like I said, the last case I saw was some years ago. And there is a reason “private” exists at all.
Could you give me an actual example in UE where I would want to take away from all derived classes to do stuff with the data that MAKES the class what it is?
I just think that each and every case of “private” I have seen in the last months is not needed or just plain wrong.
If you take away something from derived classes, you need a good reason.
I am not trying to defend the approach Epic has chosen as it is confusing but I can see where they are coming from.
Making things private rarely has anything to do with security but rather you are showing what the variable is intended for and more importantly not intended for.
Blueprint is often more open in regards to access while C++ keep access as limited as possible to guide the reader in the right direction without having to dive into the implementation.
You could make everything protected or public but now you are pushing responsibility beyond the base class.
It looks a bit strange that a programmer (who usually knows what he is doing) does not have access to a given variable, but a person working on blueprints (who is not always a programmer and does not necessarily need to know or knows what he is doing) has access to it.
It may be that “AllowPrivateAccess” was introduced clearly as a hack for a specific purpose in specific situations by Epic devs, and the rest just copy this solution without realizing the consequences of this approach.
Defining something in the private section means “nobody never anywhere has the right to even touch it except me” From a debugging point of view, this is extremely important.
This might be it.
It sounds reasonable and would explain it.
There might still be something we don’t know but for now I am going with your explanation.
It should not be important, but … it always gnaws somewhere in my brain if don’t see an explanation for certain things. And I can’t decide which things these are. So: Thank you!
Yes. I think this is true too.
We have in most cases the possibility to just copy a class and move stuff from private to protected IF we wish to do it.
So, putting something into the private area might be like “I need that, but please don’t touch it, don’t even think about it, you are probably not smart enough to use it correctly”, which sounds not like a C++ thingy but like something someone coming from another language would do.
Perhaps this “showing intention” together with the content of the post of Emaer can be mixed together to give an answer which can make me forget about the whole thing.
Thanks to both of you!