[swift-evolution] Draft proposal: multi-property assignment .= operator

[Michel Fortin]

Le 10 janv. 2016 à 18:12, Tino Heth <2th at gmx.de> a écrit :

> Methods like "setValuesForKeysWithDictionary" can indeed be very handy — but its name is quite verbose, and imho that isn't that bad:
> It's hard to guess the meaning of ".=" (I'd prefer "<-" instead, but I guess depending on the background of the reader, this may be as hard to understand)

I choose `.=` because it's an assignment (hence `=`) to member properties (hence `.`). What is the meaning of `<-`?

> A method with the functionality would be nice, and the possibility of compile time checking would make it better than the variant with dictionaries — but to make the check working, this method would need special treatment by the compiler, and that would appear strange to me.

What I'm proposing is to use a tuple, not a dictionary. With a tuple, the "keys" are always known at compile time because they're part of the type.

> You've written about the older proposal sketches for cascading; have you seen the following idea?
> object.{
> 	property1 = 1
> 	property2 = "a"
> }
> 
> It is a less flexible in some aspect (the tuple in your draft could be created by a function call*), but is even more concise (not much, though) and can be used for more than assigning properties.

Sure I've seen it. It's a completely different concept though: the braces suggest that you have code inside, not a list of values. Because you're bringing all the members in the local scope in that block, it makes unintended ambiguities and/or shadowing inside this code much more likely (you already have global + self members + local scope variables, now you're adding member variables from elsewhere that can shadow even your local variables). I'm sure I pointed this out before in an older thread. The tuple-assignement version has no such problem.

> * If you continue with your draft, I suggest to explore this possibility further: With a function to turn members of an existing object into a tuple, or the option to selectively remove elements from a tuple, it could be a handy way to create copies.

I probably won't pursue it further since the general response was not much positive.

-- 
Michel Fortin
https://michelf.ca