[swift-evolution] Assigning to 'self' in protocol extensions

rintaro ishizaki fs.output at gmail.com
Fri Jan 20 02:21:54 CST 2017

2017-01-20 16:11 GMT+09:00 Slava Pestov <spestov at 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

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170120/b42325cb/attachment.html>

More information about the swift-evolution mailing list