I have been wanting to have this before, but I think it is now not needed
because reflection may (or should in the long run) add the capabilities
needed to achieve this without a new keyword.

// Robin

On Mon, Dec 16, 2024, 06:57 Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I think that this solution is solving the problem in too unusual and
> narrow of a way to justify making such core language changes.
>
> Making a getter is already a viable solution to this problem. Also
> keep in mind that getters aren't just there to prevent mutation,
> they're also there to obscure layout. For example, you can internally
> store a std::string but return a std::string_view, which gives your
> class the freedom to store a C string or std::string_view as well, if
> need be. Or similarly, you can store an unsigned char but return
> std::size_t in a getter.
>
> Furthermore, getters can prevent the user from taking the address of
> the data members, which also gives you flexibility to change the
> layout in the future. If someone is able to do &foo.value and expects
> this to be an int*, you definitely cannot change the class layout
> later without breaking code.
>
> If you're going to approach this problem of getter/setter boilerplate,
> it should probably be done through properties. Last proposal that
> addressed those was
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf.
> Personally, I don't think that properties are a good fit for C++
> though, so there's really nothing that can be done here.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>