Re: [swift-evolution] Class mutation model and value-constrained protocols

I definitely see Dave’s point here. It seems to me we can only get generic to the point at which the semantics change. So methods that don’t have any mutating consequences can be applied to any value such as Structs and Classes, but when the semantic relates to mutation, we can only apply that

Re: [swift-evolution] Class mutation model and value-constrained protocols

> > If we are going to maintain source stability after Swift 3, it seems > that we either need to address this now, or decide that it won't be > addressed, because of the “viral const” problem. > IMHO immutable instances and value vs reference allocation are separate concerns. Just like you

Re: [swift-evolution] Class mutation model and value-constrained protocols

> On Jul 5, 2016, at 4:15 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jul 05 2016, Chris Lattner wrote: > >>> It's also possible that I've overestimated the seriousness of the issue >>> and we actually can afford to postpone thinking about it until

Re: [swift-evolution] Class mutation model and value-constrained protocols

Comments inline. > On Jul 5, 2016, at 2:11 PM, Dave Abrahams wrote: > > > on Tue Jul 05 2016, Jonathan Hull > wrote: > >> Comments inline >>> A “mutating” keyword on a protocol method is only useful if >>> you can reason about the mutation in

Re: [swift-evolution] Class mutation model and value-constrained protocols

on Tue Jul 05 2016, Chris Lattner wrote: >> It's also possible that I've overestimated the seriousness of the issue >> and we actually can afford to postpone thinking about it until after >> Swift 4. > > There is no chance that we will have time to re-evaluate this for Swift 3. There are too

Re: [swift-evolution] Class mutation model and value-constrained protocols

on Tue Jul 05 2016, Jonathan Hull wrote: > Comments inline >> A “mutating” keyword on a protocol method is only useful if >> you can reason about the mutation in generic code. >> >> protocol P { >> mutating func changeMe() >> func noChange() -> Int >> } >> >> In other words,

Re: [swift-evolution] Class mutation model and value-constrained protocols

On Jul 5, 2016, at 10:53 AM, Dave Abrahams via swift-evolution wrote: > When T is a class type, it can easily violate *all* of these > expectations. In other words, classes naturally bypass the mutation > model. > > If we are going to maintain source stability after

Re: [swift-evolution] Class mutation model and value-constrained protocols

Personally, I'm fine with current state of things. Firstly, I consider classes like a compatibility feature. They slightly fall out of Swift type system. One can almost entirely avoid them, except when interacting with ObjC. (They somehow code in Haskell, right?) Secondly, when we interact with

Re: [swift-evolution] Class mutation model and value-constrained protocols

>> 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

Re: [swift-evolution] Class mutation model and value-constrained protocols

Comments inline > A “mutating” keyword on a protocol method is only useful if > you can reason about the mutation in generic code. > > protocol P { > mutating func changeMe() > func noChange() -> Int > } > > In other words, given x of some type conforming to P, it should be >

[swift-evolution] Class mutation model and value-constrained protocols

A “mutating” keyword on a protocol method is only useful if you can reason about the mutation in generic code. protocol P { mutating func changeMe() func noChange() -> Int } In other words, given x of some type conforming to P, it should be meaningful that this is an error: