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_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>