SE-0400: Init Accessors

[Jumhyn (Frederick Kellison-Linn)]

Taking off my review manager hat for a moment, I have a few thoughts/questions:

• I agree with @DevAndArtist's comment from the pitch thread:

  @DevAndArtist

  • I would not force newValue bacause that's not a setter where the value changes. Personally I would prefer value or initialValue to make it clearer.

• I still don't like the restriction that the ability to synthesize a memberwise init depends on the relative ordering of properties and their accesses clauses. Since accesses clauses can only refer to stored properties there's no chance of cycle, and IMO we should synthesize a memberwise init with the parameters matching source order but with properties initialized in dependency order (ties broken by source order).

• To Jordan's point above:

  @jrose

  Ah, I see, this is specifically for things like the dictionary-backed properties where skipping them should still be considered an error.

  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?)

ETA:

• Does invoking the setter of a stored property in an init accessor (can you do this?) invoke the didSet observer? IIRC the current rule is that setters called inside init never call didSet, seems like we should extend that to init accessors.

@tourultimate

Also, a nice simplification might be to have the ability to bundle the init and set accessor so for less boilerplate where init/set have the same logic:

struct Angle {
  var degrees: Double
  var radians: Double {
    get { degrees * .pi / 180 }
    set init initializes(degrees) { degrees = newValue * 180 / .pi }
  }
...
}

I noted myself as weakly against this direction in the pitch, but I think one thing to consider with the new syntax that puts the initializes and accesses clauses outside the init clause, a future direction which allows combining the init and set accessors is IMO significantly more awkward (it's not clear that initializes really only applies to the init and not the set). I guess you could just learn this, but it's something to consider...