Honestly no IMO... The thing with the reflection implementation is that you
not only would be able to expose the API from another type, you will also
be able to add stuff to it. If we really want to make things "easier" we
should work to add to the class-type-thing that Herb Sutter proposes, i.e.
the:
```cpp
class(foo) bar {...};
```
thing. Like, letting it have parameters or something that allows us to do
something like:
```cpp
class(exposing(<member>)) foo {
<member> ...};
```

Note: exposing is not a keyword here.

On Mon, Dec 16, 2024, 07:38 James <james.business.84_at_[hidden]> wrote:

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