Open design idea: properties

[chandlerc]

Disclaimer

This issue is part of a series that are just recording language design ideas that have come up for Carbon. It isn't necessarily a good idea, or one that Carbon should definitely adopt. However, it is an interesting area that has come up several times and seems to at least be promising. But it still might not work out!!

Before picking up a language design idea like this and fully developing it, we encourage you to find some folks who are very active in Carbon's language design (as well as potentially one of the leads) and discuss the area with them to get a feel for what would make sense, challenges they anticipate, etc.

Properties

"Properties" in programming languages are a way to begin defining more of an API around fields.

https://en.wikipedia.org/wiki/Property_(programming)

These seem really interesting to help with a number of use cases:

• Exposing a field as part of the public API while retaining the ability to maintain invariants.
  • This avoids having to define methods (and pick names for methods) that do nothing other than model "get" and "set" access to the field.
• Provide a friendly field access model even with complex storage models such as bit packing
• Synthesize field-like behaviors for a class through some computation of the actual fields.
  • A particularly interesting capability is evolving fields over time, where properties allow decoupling the update to the storage model and the interface.

Many other languages have features in this space. Some good places to research before digging into how Carbon should approach this:

• https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties
• https://docs.swift.org/swift-book/LanguageGuide/Properties.html
• https://kotlinlang.org/docs/properties.html
• https://www.typescriptlang.org/docs/handbook/2/classes.html#getters--setters (I think? Not a TS expert...)

Some key ideas in @chandlerc's mind to make a properties design for Carbon compelling:

• Really smooth transition from field-with-trivial-accessors -> field-with-interesting-accessors -> fully-computed-property
• Somewhat expect even trivial properties with a field backing them to be significantly more restricted than fields.
  • Readonly properties should be modeled like let bindings as R-values.
  • Open question about whether mutation should be encapsulated (not exposing the address), or as an L-value with an address. This should be explored in the design.
• Would like the syntax and semantics to be so friendly that it is easy to heavily recommend properties in the public API
  • Instead of public fields for types with any level of invariants at all. (IE, not boring data classes.)
  • Instead of methods that in essence just act as getters or setters for fields.
  • For example, many classes have read-only fields with getters (but no setters). Would be great for these to always be modeled with properties to avoid using method names & syntax.
• Ideally, would like to reduce the proliferation of almost-colliding names. Goal would be to use a single name for the property accessed and the field storage (if it exists).

Others (especially leads) should feel free to add specific considerations in their minds here.

[JamesJCode]

+1 for this goal:

Ideally, would like to reduce the proliferation of almost-colliding names. Goal would be to use a single name for the property accessed and the field storage (if it exists).

This is one thing that can make properties really messy in some other languages.

[josh11b]

Another idea (which I think Swift supports): making it easy for a property declaration in an interface to be backed by a field in a class implementing that interface. This would close a gap where interfaces currently only have functions and types, not data.

[chandlerc]

Another wrinkle to think about here is out-of-line definitions. I can imagine this being especially useful in some cases for example to manage dependencies on assertion / logging frameworks that are implementation details and shouldn't be in the interface.

[tkadur]

General thought - should this be special-cased in the language or done with static reflection/metaprogramming?

[jonmeow]

General thought - should this be special-cased in the language or done with static reflection/metaprogramming?

One of the possible advantages of properties is that they could look identical to member access. That way, members and properties can be transparently swapped without modifying callers. i.e., given the code foo.bar, this could either be accessing a member bar on foo, or using the property bar on foo.

The interchangeability is advantageous both because it allows switching the implementation without modifying callers, and also because it allows a developer to swap direct member access with a property that would allow breakpoint-based debugging within the property access (which a simple member doesn't support quite so well).

If property access is identical to member access, that likely means some special-casing in the language in order to avoid function-like parentheses, i.e. foo.bar().

[josh11b]

One concern I have is that the "set function" paradigm is in conflict with the "all mutation happens through a pointer" paradigm. In particular, right now in Carbon all member functions that mutate a value of a type involve passing a pointer to the value, and all other mutations, like assignments, are going to be rewritten into such calls. I'm particularly concerned about properties being slow due to having to make a bunch of unnecessary calls to the get and set functions when inlining (either the property's functions or the mutations being applied to the property) is not possible.

[joseviccruz]

Hey folks! What is the status of this issue? Is this still something to be considered / has it already been addressed?

[lexi-nadia]

I'm certainly not working on it anymore...