That would be a getter, which the OP was trying to avoid... I guess the OP
would like to declare things that looks like 'member fields' but in reality
are 'member functions'. Not sure how that would end up though.

// Robin

On Mon, Dec 16, 2024, 13:30 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Wouldn't that increase the class size by one pointer value?
>
>
>
> One could alternatively provide a function instead
>
>
>
> const int& readOnlyValue() { return value; }
>
>
>
> That would also survive a trivial copy.
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Oskars Putans via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mo 16.12.2024 11:11
> *Betreff:* Re: [std-proposals] New access specifiers
> *An:* std-proposals_at_[hidden];
> *CC:* Oskars Putans <o.putaans_at_[hidden]>;
> 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
>