[swift-evolution] [Proposal Draft] partial initializers

[Brent Royal-Gordon]

Let's start with this:

>> , and the compiler will need to make sure partial method calls are ordered such that everything needed is already initialized; it's simply a question of whether we declare what's needed or automatically detect it. I've noticed in previous proposals that scanning the method body is disfavored, so I figure that's not our best bet here.
> 
> This is another reason I am not sure about this.  I think you are right that this would require a declaration.  It becomes much more verbose that way.

The compiler will absolutely, 100%, inescapably need to know which properties a given partial method initializes. Otherwise it can't properly perform its phase one check, and if this proposal breaks safe initialization, it's not going to be accepted.

We could specify that the compiler takes a peek at the implementation and figures out which fields it initializes, or we could specify that the method declares the fields it will initialize. But however we choose to do it, doing it in *some* way is not negotiable.

>> I think that many, possibly most, partial methods—especially those that are meant to be called as normal methods will need to access existing properties
> 
> Do you have some concrete examples?  I’m sure this would be useful in some cases, I’m just not sure whether we need to include it right away.  

Sure. Let's extend your resetting example so that the value you can reset the property *to* is configurable:

	struct Resettable<Value> {
		private let initialValue: Value
		var value: Value
		
		partial(uses initialValue, inits value) mutating func reset() {
			value = initialValue
		}
		
		init(_ initialValue: Value) {
			self.initialValue = initialValue
			reset()
		}
	}

> If the memberwise init review is anything to go by, there will be a lot of pushback that something like this makes the proposal too complex.  People might warm to it more after using the basic feature for a while and realizing the limitation this poses in practice.

You don't want to make things overly complicated, but you also don't want to ignore obvious needs. In hindsight, SE-0019 made both of those mistakes in different places.

> One thing I would be concerned about is that the compiler will enforce proper order during initialization, but it will not enforce anything later.  If you are resetting state you will be on your own to do things in the correct order.  If the partial inits are not able to read from a property they didn’t write that at least helps prevent mistakes during the reset sequence (of course at the cost of some flexibility in structuring your code).

I'm not really sure why this is a concern. After `init` finishes, none of the fields you access could be uninitialized. There's nothing built in to Swift that lets you ensure methods are only called when the instance is in a state that expects them; all you've got for that is precondition(). I just don't see how this is any worse than what we've already got.

-- 
Brent Royal-Gordon
Architechies