I know that I am not addressing some points that others may have made, I
don't care.

TL;DR all of the "is to" / "is not"

I am against this for purely religious reasons.
1) Class encapsulation says that the class interface should hide and
protect the implementation.
2) Internal data members should NOT be directly exposed to the outside
world (No get()'ers & set()'ers)
2.a) That is what member functions are for getting/setting and
manipulating data members.
3) I don't care what other languages do. If it is not a good idea, it is
not a good idea, stop!
4) Don't add more hidden magic.
4.a) We should not be adding features purely as a way of saving typing that
can already be done in existing code (manually coding a get()'er function)

Get()'ers & Set()'ers expose and lockdown the implementation.
If you need to refactor the class internal implementation you break all of
the code using this class.
If the internal implementation needs to change, you change it in the
interface member functions that manipulate the internal data.

Also:
What about if you needed to make the get()'ers & set()'ers virtual? Are you
going to make a data member virtual?
What about name blocking in a derived implementation, how would that work.
Too messy
What about base class/struct inheritance public/private/protected. Strictly
speaking a base class/struct is a member. If members can have your exposed
private (or exposed protected) then the base class/struct must have them.
Get at a base, isn't that done through casting (or member functions)? What
about multiple inheritance, (and/or virtual inheritance)?
A member is a member, no special casing, too many weird corners.

Keep your privates private.

Simplify !


On Sun, Dec 15, 2024 at 9:08 PM James via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> In C++, it’s common to encounter situations where a member variable needs
> to be fully controlled by its owner class but also readable from outside
> the class. The typical solution is to define a public getter for the
> variable:
> ```cpp
> class Foo
> {
> int value = 0;
> public:
> int get_value() const { return value; }
> };
> ```
>
> I propose two new access specifiers to make this process easier. First one
> is "exposed private". Member variables defined after this specifier would
> allow anyone to access these variables as const, but only owner class to
> modify them.
> The other specifier is "exposed protected", it's the same as before, but
> also allows derived classes to modify these variables.
>
> So previous code could just be rewritten as following:
> ```cpp
> class Foo
> {
> exposed private:
> int value = 0;
> };
> ```
>
> It's less boilerplate and you get to refer to the variable with its
> original name.
> ```cpp
> Foo foo;
> int value = foo.value; // ok
> foo.value = 15; // error, can't modify const variable
> ```
>
> Note: I'm not sure about naming and I'm open to ideas. Also the exact
> thing I just specified might contain issues, but you get the idea.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>