[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

[Paul Cantrell]

Before diving into the details, I’d like to reiterate the point of my review:

I don’t know exactly what the better mechanism is, but I strongly suspect that it’s out there. My wish is to defer the current very narrow proposal in favor of a more searching for a general mechanism.

I don't think we should permanently reject a thoughtful proposal only because a better proposal might be out there. Neither do I think that having to come up with a better mechanism within the review period should be a requirement of not immediately accepting the proposal.

That’s the upshot of my review. The rest of this message is just noodling….

> Brent Royal-Gordon <brent at architechies.com> wrote:
> 
> I don't think the `members` tuple is a good alternative here. It looks good on paper, but think about what it actually would need to involve to match this proposal and its likely enhancements:
> 
> - It would need to have different elements at different levels of accessibility, and we would somehow have to select the right level for the matching initializer.
> - It would need to include only properties *writable* at that level.
> - It would need to include only stored properties.
> - It would need to include only properties that are either `var`s or uninitialized `let`s.

You’re imagining with all these that the initialization code must be _completely_ synthesized. But as I said, I’d happily shoulder the burden of just a little more explicitness if I got a mechanism that wasn’t so inflexible as the proposal at hand.

I’m quite sure that the automated synthesizing won’t always get it right. It tries, but I’ll want inevitably want manual control. And thus…

> - But we would need mechanisms to add items that have been excluded, and remove items that have been included.

…I’d want such mechanisms with the current proposal too — but there’s no obvious future expansion direction for them.

> Plus there's all the weirdness around using it to reassign constants.

It would follow the same rules as normal assignment. No weirdness there.

> On Jan 10, 2016, at 3:37 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> On Jan 10, 2016, at 1:17 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>> Yeah. Still brainstorming here :-)
> 
> So you know, I didn't really mean to put you specifically on the spot here; you're obviously trying to find concrete solutions to these problems. But it seems to me that what we're going to end up with is that, instead of having this:
> 
> 	public init(members...: Members) {
> 		self.members = members
> 	}
> 
> We'll have something more like:
> 
> 	public init(members...: Members.Public.Initializable) {
> 		self.members.public.initializable = members
> 	}

Well, in my brainstorms, I was loosely imagining that when members is used as an lvalue, it would infer the subset being assigned to using the labels of the rhs tuple. So you could do this:

	public init(members...: Members.Public.Initializable) {
		self.members = members
	}

…or maybe something more arbitrarily composable:

	public init(members...: Members.only(public, var, except: meaningOfLife)) {
		self.members = members
                meaningOfLife = 42
	}

…or even:

	public init(members...: Members.only(public, var).except(meaningOfLife)) {
		self.members = members
                meaningOfLife = 42
	}

Breaking that down:

	Members.only(public, var) → (a: Int, b: String, meaningOfLife: Int)
        .except(meaningOfLife) = generic operation that works on any tuple → (a: Int, b: String)
	members arg then gets a value like (a: 4, b: “foo”)
	self.members = (a: 4, b: “foo”) infers that a and b are being assigned to, and expands to:
		a = 4
		b = 4
	…with no additional language features necessary for access control, let/var, etc.

Something like that. Who knows? It’s obviously a complicated discussion. The point is just that it would do a lot more for the language to have orthogonal features for:

turning tuples into variadic parameters,
turning member or member types into a tuple, the former of which can be an lvalue, and
subsetting and reordering tuples.

…with none of those being limited to initializers.

Some mechanism like this would generalize much better than the current proposal, which breaks down quickly if you step outside its imagined use cases.

I don’t see the current proposal leading in this more useful direction, though it sounds like Matthew has something up his sleeve.

Cheers,

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160110/c03c0f05/attachment.html>