The discussion moved to properties, which I am not against, however I don't believe, they remove the need for some zero-const member reference for structs.
After all, the original requirement is to not have a function, just to provide a public read. "Renaming" fields is definitely still valuable as well.

Granted, properties are a million times more useful in general, but are still quite heavyweight for structs.

On Wed, Jan 15, 2020 at 5:57 AM jianping z via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
as read/write properties can be used widely for various purposes, for
example, read property can be used to get computed value from an object,
or access a member value of an lvalue/rvalue object (const or not
const), we should not restrict types of  return/param values of a property.

1) there should be no type restriction for return value of a read
property, it could be a value, an object, a reference, a pointer, an
rvalue reference etc, const or not const.
2) there should be no type restriction for return value of a write
property too, in addition, write property could have no return value
(void) when needed.
3) there should be no type restriction for param value of a write
properties too.
4) property overload and template should also be supported

for sure, we still need some restrictions for property,

1) read properties should have a return value, and have no param value.
2) write properties should have a param value,  return value is optional
(no return value is ok)
3) overload/template declarations of a property must not conflict, so
for assignment operation on property, compiler can make clear choice
which definition to use depending on the type of param/return value.

Thanks,
Jianping

On 1/14/2020 12:17 PM, Thiago Macieira via Std-Proposals wrote:
> On Monday, 13 January 2020 20:06:48 PST connor horman via Std-Proposals wrote:
>> I’d recommend having read/write properties return a reference, and
>> potentially having read properties return a const reference, and otherwise
>> be similar to methods (cv-qualifiers, ref-qualifiers, etc)
> So long as that's a recommendation, not required, that's fine.
>
> Because I recommend property getters always return by value, never a
> reference. That allows you to change the internal implementation to hold
> something different.
>

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