>> 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... +1 l8r Sean _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
