Keep in mind, it doesn't have to be a new keyword. Could be an existing one
overloaded or maybe a property/qualifier on the variable itself. I wanna do
a little brainstorming here, I think we can do better than the one I
proposed.
We can have the same behaviour with reflection or manual implementation,
but I think there is still some value in this. It makes
programmers intention very clear with less code.

On Mon, Dec 16, 2024 at 9:10 AM Robin Savonen Söderholm <
robinsavonensoderholm_at_[hidden]> wrote:

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