On Mon, 16 Dec 2024 at 10:33, Oskars Putans via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I'm fairly certain this copies and moves don't break the reference as it
> always references the local variable, not the other variable.
>

You need a user-provided copy constructor to ensure that it references the
local variable.



> Because both the member and the reference have the same lifetime, it
> shouldn't under any circumstances be dangling.
>
> Can you provide an example where this does break?
>
>
> On Mon, 16 Dec 2024, 12:23 Robin Savonen Söderholm, <
> robinsavonensoderholm_at_[hidden]> wrote:
>
>> First I have to apologize, I misunderstood the feature... You mean that
>> you want to have something like the getter/setter decorators used in Python?
>>
>> Secondary, the ref thing is broken because it would be wrong or even
>> dangling reference the moment Foo is copied/moved.
>>
>> // Robin
>>
>> On Mon, Dec 16, 2024, 11:11 Oskars Putans via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> What if you used
>>>
>>> class Foo {
>>> private:
>>> int value;
>>> public:
>>> const int& readOnlyValue = value;
>>> };
>>>
>>> as a way of exposing a const version?
>>>
>>> It might not work in all use cases as it does remove
>>> std::is_trivially_assignable trait from
>>> the class, but this gets rid of an explicit getter and reduces
>>> boilerplate. If you want to support assignment, you need to write your own
>>> overloads. This method is slightly shady, however, as other developers
>>> might make
>>> the assumption that this value won't change. I would rather use getters
>>> for this, but this is one alternative you can consider. Realistically, as a
>>> proposal to core cpp, there's a very low likelihood that this would make
>>> the cut.
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>