2017-01-20 16:11 GMT+09:00 Slava Pestov <spes...@apple.com>: > > Is your proposal to ban calls to such mutating methods on a type that is > known to be a reference type at compile time altogether? This will create > an inconsistency between code that operates on concrete types and code that > operates on generic parameters (in the latter case the compiler of course > has no way to statically guarantee that the value is not a reference type). > > The last time this quirk came up in internal discussions, the thought some > of us had was that it might be worthwhile to prohibit classes from > conforming to protocols with mutating requirements altogether. If you think > about it, this makes some amount of sense — it seems like it would be quite > hard to write code that can operate on both mutable values and mutable > references generically, since the latter do not have value semantics: > > var x = y > x.mutatingProtocolRequirement() > // did y change too? > > However the discussion sort of fizzled out. > > Perhaps we can resurrect it as a proposal, but the bar is pretty high for > removing features at this point, since there’s no actual type soundness > issue, just possible confusion. > > Well, I'm not proposing anything for now. I'm totally OK to leave it as is if the community think so. If so, I just want to confirm that the language feature truly support this. At least, I don't want to propose something that breaks source compatibility.
> Default implementation for initializers > > Similar to methods, initializers also have this issue: > > In the specific case of initializers, my opinion here is the opposite in > fact — I think assigning to ‘self’ should be permitted in all convenience > initializers, even initializers defined directly classes, without the > protocol extension trick. Also, we should lower this more efficiently than > we do today, without creating a self ‘carcass’ that is allocated and > immediately freed, to be replaced by the ‘real’ self. > > I totally agree. And I think that is the least impact way on the language specification.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution