SE-0400: Init Accessors

[hborla (Holly Borla)]

@jrose

How use-sensitive is this? If the init accessor is used from one @inlinable init, diagnostics may start appearing in the body of the init accessor that weren't there before, correct? What if the init accessor is used from one init, but it's another init that's inlinable?

I was imagining that you need to write @inlinable on the init accessor explicitly in order to use it from an @inlinable initializer, but I can see how the proposal is totally not clear about that!

@tourultimate

Can the initialValue be implied, just like newValue is with set accessor

The implied parameter is called newValue, which is deliberately consistent with set. The reason to use newValue instead of initialValue is because the word "new" still fits with initialization; you are indeed providing a new value to the field when you are initializing it. I also wanted to avoid adding another magic parameter name that people need to discover and then remember. I don't really see a strong motivation to introduce initialValue instead of newValue here.

@graskind

How do these initializers interact with Codable, especially compiler-generated Codable conformance?

init accessors don't interact with synthesized conformances at all. Those conformances still look specifically at the set of stored properties. It's plausible that the generated conformance could use the same strategy that member-wise initializers have in this proposal, but that would be a semantic change to the way property wrappers behave today. However, this feature might allow you to write Codable conformance synthesis through a macro that has the behavior you're after, where the conformance is based on the "original" stored properties as written (e.g. before any property wrapper or macro transformations happen).

@Tim.Wang

Since the init to the computed variable is so special, could we just put this part in brackets like below and leave the body of the computed variable untouched?

I don't think init accessors are any more special than get and set accessors.

@Jumhyn

• is there a reason that we must support this (init accessors which don't actually initialize anything)? It doesn't seem necessary for subsuming property wrappers, so I'm curious if we just ought to leave it out. It seems somewhat esoteric. But if there's a super compelling use case I'd love to hear it! (E.g., is this support necessary for Observable?)

It's not necessary for @Observable, which backs every computed property by a stored property. The dictionary storage example in the proposal is a proxy for use cases that back all properties by some external storage mechanism, such as @Model from SwiftData or the Realm use-case mentioned at the end of the SE-0385 motivation:

Consider the Persisted property wrapper from the Realm package:

@propertyWrapper public struct Persisted<Value: _Persistable> { ... } 

class Dog: Object { 
  @Persisted var name: String 
  @Persisted var age: Int 
}

To support advanced schema customization, the property wrapper could store a string that provides a custom name for the underlying database column, specified in the attribute arguments, e.g. @Persisted(named: "CustomName"). However, storing this metadata in the property wrapper requires additional storage for each instance of the containing type, even though the metadata value is fixed for the declaration the property wrapper is attached to. In addition to higher memory overload, the metadata values are evaluated eagerly, and for each instantiation of the containing type, rendering property-wrapper instance metadata too expensive for this use case.

[...]

Combined with attached macros, the @Persisted property wrapper in Realm can evolve into a macro attached to persistent types, combined with custom metadata attributes that provide schema customization for specific declarations

I believe these use-cases really do want diagnostics in the case where you forget to assign to one of the computed fields in an initializer.

@Jumhyn

Yeah, I'm thinking of cases where it would be (dynamically) valid to call didSet, similar to:

Ah, we totally could make this work using the same strategy in definite initialization that chooses between an init accessor call or a set accessor call, but this proposal does not include this change. However, if an assignment to a computed property in an initializer is re-written to a set accessor call and that set accessor assigns to a stored property, the observer for that stored property will indeed be called (this is not new behavior in this proposal). But inside of an init accessor, property observers are never called.