Struct properties

[joshtriplett]

I'd like to have syntax for defining named "properties" on a struct. A property would consist of a name, a type (which may use in-scope generics), an optional get function (taking void and returning the field type), and an optional set function. (The name and the get/set function can each independently have "pub" visibility or not.) A property will not have any storage allocated for it in the struct layout; instead, attempts to get or set the property will become calls to the get or set function. A property with no get or set function specified will produce a compile-time error on an attempt to get or set it, respectively.

The get function would take no arguments and return a value of the field type, and the set function would accept a value of the field type and return nothing. In both cases, it would also work to accept/return a reference with appropriate lifetime.

In addition to the convenient syntax and encapsulation, this would then support several useful cases. Most notably, it would support migrating an existing field to a property, removing it from the structure layout while maintaining compatibility with previous code that accessed it via field syntax.

[sfackler]

It'd have to be a bit more than just a getter and setter to allow migration from a field to a property without breaking anything, since code that took a reference to the field would break.

[joshtriplett]

That could potentially be covered by the "reference with appropriate lifetime" version of get/set. In the absence of that, for some structure fields it may work to simply produce a compile-time error on an attempt to take a reference, as though attempting to take a reference of an rvalue.

[Gankra]

@joshtriplett how does one return a reference to a value that is computed by a getter? Also pattern matching/destructuring might be tricky.

[Gankra]

I suppose temporary locals could be made at the call-site to store the value for destructuring and references?

[joshtriplett]

@gankro

@joshtriplett how does one return a reference to a value that is computed by a getter?

The getter could return a reference with the same lifetime as the structure the getter is called on.

Also pattern matching/destructuring might be tricky.

How so? Seems straightforward enough to pattern match or destructure on the return value of a function.

[sfackler]

Where would that reference point?

[acertain]

The get function would take no arguments and return a value of the field type, and the set function would accept a value of the field type and return nothing. In both cases, it would also work to accept/return a reference with appropriate lifetime.

Shouldn't it have access to self?

It'd have to be a bit more than just a getter and setter to allow migration from a field to a property without breaking anything, since code that took a reference to the field would break.

How so? Assuming it works without references, taking a reference to the return value of a function let a = &foo(); works.

[sfackler]

@fread2281 let a = &foo(); is equivalent to let _tmp = foo(); let a = &_tmp;. It's a reference to a new slot on the stack, not the slot in the struct. There's no way to make code like let a = &foo.bar continue to work without any changes if the only API is get and set if get returns a value and not a reference.

[acertain]

@sfackler Sure, but properties are still useful, and I don't think there's a way to make getters that allocate their return value lifetime-compatible (where do you insert the drop()?). Also, different variants would be useful: I would like a version that allowed me to return &'lifetime_of_struct T since I only want to overload the setter, and use a priv field for the getter.

[Centril]

@joshtriplett still interested in this or shall we close?

[peterkos]

This is an old issue but as a Rust user coming from Swift's computed properties, it can be very handy at times for abstracting away small computations or adjustments in a type!

[burdges]

I think this issue should be close in favor of https://github.com/nikomatsakis/fields-in-traits-rfc because methods cannot addresses the related borrowing concerns without partial borrowing #1215 (comment)

[helltraitor]

This can be done with macros, isn't?
You can try this, for example: https://docs.rs/getset/latest/getset/

So, I want you (or moderation) to close this, please. I don't think that this feature is really worth it