-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Struct properties #419
Copy link
Copy link
Open
Labels
A-data-typesRFCs about data-typesRFCs about data-typesA-expressionsTerm language related proposals & ideasTerm language related proposals & ideasA-syntaxSyntax related proposals & ideasSyntax related proposals & ideasA-typesystemType system related proposals & ideasType system related proposals & ideasT-langRelevant to the language team, which will review and decide on the RFC.Relevant to the language team, which will review and decide on the RFC.
Metadata
Metadata
Assignees
Labels
A-data-typesRFCs about data-typesRFCs about data-typesA-expressionsTerm language related proposals & ideasTerm language related proposals & ideasA-syntaxSyntax related proposals & ideasSyntax related proposals & ideasA-typesystemType system related proposals & ideasType system related proposals & ideasT-langRelevant to the language team, which will review and decide on the RFC.Relevant to the language team, which will review and decide on the RFC.
Type
Fields
Give feedbackNo fields configured for issues without a type.
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.