[swift-evolution] Class mutation model and value-constrained protocols
sean at fifthace.com
Tue Jul 5 14:13:18 CDT 2016
>> One idea that Jordan and I have floated is that protocols with mutating
>> methods should be constrained to applying to non-class types. That
>> would be a step in the right direction, but, that still leaves cases
>> like gg able to easily violate expectations when the protocol in
>> question has no mutating methods.
> I really *dislike* the approach of disallowing class types for protocols with mutating methods, unless an additional reference type is added. I have several protocols which have conforming classes and structs and that that lets you choose reference vs value semantics.
> I would much rather have us mark class methods as mutating when they change the class’s value, and just having the concept be separate from let/var in that case.
Agreed - I think it’d make more sense this way, too. In some ways, I’m not sure why we don’t just require all mutating methods - even in classes - be declared as such, but perhaps that’s a can of worms and/or boilerplate?
>> Another possibility would be to formalize the idea of value semantics in
>> protocol declarations, so that non-class protocols were only allowed to
>> apply to values.
> I would like to have a way to require value semantics in a protocol (similar to how we can require ‘class' now). I still really want/need the ability to have a protocol which can be adhered to by both value and class types though...
More information about the swift-evolution