Pitch: Property Delegates

[Douglas_Gregor]

@Chris_Lattner3

“Branding” question: why not call them property macros ? Doing so suggests a better (IMO) syntax: instead of the weird kotlin syntax:

var foo by Lazy : Int = 1738

You get the nicer syntax of:

#Lazy var foo : Int = 1738

This is excused by saying that “# is for macro’y stuff” and that syntactic expansions are (hygienic!) macro-like. I expect to see more macro’y stuff done like this in the future (e.g. when we push protocol synthesis out of the compiler some beautiful day), and this gives us a common conceptual place to hang all of it.

As a feature name, I feel like "property macros" is too generic---it both overpromises (I should be able to define a macro to do anything with a property) and says too little (well, what can I do with them?). That said, I agree that the #Lazy syntax evokes macro expansion, which fits the way in which property delegates are used. It scales okay to the initialization case:

enum GlobalSettings {
  #UserDefault(key: "FOO_FEATURE_ENABLED", defaultValue: false)
  static var isFooFeatureEnabled: Bool
  #UserDefault(key: "BAR_FEATURE_ENABLED", defaultValue: false)
  static var isBarFeatureEnabled: Bool
}

Others have suggested using attribute syntax (e.g., @Lazy) or embracing the $ also for the declaration side ($Lazy); I prefer it to those options because we've already set aside # for things in this space. That said, it makes placing any modifiers (like public to making the storage property visible) a bit awkward---if they go in the parentheses, they look like initialization arguments, but there's no other natural space for them.

@Chris_Lattner3

$ Syntax and access control : The synthesis and exposure of the $ members is really unfortunate and doesn't feel swifty at all. This is particularly egregious given you have two access control modifiers going on:

public var foo: Int by public Lazy = 1738

This does not dovetail well with the rest of the language and will be a inscrutable to non-experts in the feature.

We already have "multiple access control modifiers" via private(set), so the notion is not newly-introduced here. Moreover, we are declaring two entities---that's fundamentally how we describe this feature---and it is reasonable that authors could choose whether the delegate is part of their API or not.

@Chris_Lattner3

In terms of access control, I believe that you are sugaring something that doesn’t really matter. If users have direct access to the storage already, they can just explicitly redeclare it as another property, and use a propery macro to make that not totally onerous:

#Forward public var fooStorage = $foo

It is super obvious that this declares a public var named fooStorage !

Presumably, this means that #Forward is another new feature, but it's using the same syntax as a property delegate. We'll need to be careful in this syntactic space. Also, I think the relationship expressed above is backwards: we want to define fooStorage as a normal (stored?) property, and sugar the declaration of foo that delegates to fooStorage.

Syntax aside, I think your meta-point is reasonable: rather than trying to pack configurability of the storage property into the original property declaration, we could say that there is a syntax for "delegate to this other named property". With the by syntax, this can fall out as a result of name lookup referring to a property:

public var fooStorage: UserDefaults<Int> = ...
public var foo: Int by fooStorage   // okay, we found a property; delegate to that

With a # syntax, we'd probably need something special, e.g.,

public var fooStorage: UserDefaults<Int> = ...
#delegate(to: fooStorage) public var foo: Int

@Chris_Lattner3

In terms of access to the underlying storage, there are lots of things we should consider here, including stuff like #storage(yourObject.foo) , which would be equivalent to yourObject.$foo in your proposed syntax, but is more explicit about what is going on.

Yes, we could have some kind of #storage(of:). to access the backing storage. I find that to be rather verbose for the use case, but perhaps I haven't sold the use cases well enough to motivate using $. I'll see if I can do better in a revision of the proposal.

Doug