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

[Angelo Villegas]

I think the "<-" operator is better than ".=". This and cascade style assignment would be a good team for me. 
object <- {    prop1: value1,    prop2: value2}

    _____________________________
From: Tino Heth via swift-evolution <swift-evolution at swift.org>
Sent: Monday, January 11, 2016 7:12 AM
Subject: Re: [swift-evolution] Draft proposal: multi-property assignment .= operator
To: Michel Fortin <michel.fortin at michelf.ca>
Cc: swift-evolution <swift-evolution at swift.org>


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)

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.

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.

Best regards,
Tino

* 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.
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution



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