>Why would a “classical getter” necessarily return by value?  (Sure: a naive code generator might write one, but that’s a different issue)

 

 

 

A getter returning by value was mentioned in the OP:

 

 

> 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; }
};
```
 

But never mind, if the one returning by reference was already implied as an option in the discussion.

 

-----Ursprüngliche Nachricht-----
Von: Andre Kostur <andre@kostur.net>
Gesendet: Mo 16.12.2024 15:05
Betreff: Re: [std-proposals] New access specifiers
An: std-proposals@lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>;
Why would a “classical getter” necessarily return by value?  (Sure: a naive code generator might write one, but that’s a different issue)

On Mon, Dec 16, 2024 at 5:26 AM Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Fair enough.

But with the difference that a classical getter would be by value and that one would return a const reference.
 

-----Ursprüngliche Nachricht-----
Von: Robin Savonen Söderholm <robinsavonensoderholm@gmail.com>
Gesendet: Mo 16.12.2024 13:33
Betreff: Re: [std-proposals] New access specifiers
An: std-proposals@lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>;

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

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals