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

[Slava Pestov]

> On Jan 19, 2017, at 10:52 PM, rintaro ishizaki via swift-evolution <swift-evolution at swift.org> wrote:
> 
> From the perspective of the caller, I think, this behavior is counterintuitive because we use "reference types" with an expectation: the referencing address would never be changed unless we explicitly replace the object by re-assigning to the variable in call sites, e.g.,
> 
> 

Well, there’s no real difficulty here, other than potential user confusion. The ‘self’ parameter for a mutating method is passed inout, so this behaves as if you called a global function with an inout argument. The difference is of course when you pass a non-self inout argument, the compiler requires you to use the explicit & syntax at the call site.

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.

> var ref: Foo = Foo()
> ref = Foo()
>  <https://gist.github.com/rintaro/e9d606e2a6d833a043cf43a9a3e14670#default-implementation-for-initializers>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.

We already have something like this in fact, it’s called ‘factory initializers', but it’s not directly exposed through the language. It is possible to import a static method or C function as a convenience initializer on a type. The Dispatch overlay uses this for example — DispatchQueue.init actually calls dispatch_queue_create(), which returns a new instance of the type, and not [[OS_dispatch_queue alloc] init] as you would expect if this was a vanilla Objective-C class. The code that gets generated here is similar to the protocol extension initializer example you show that assigns to ‘self’.

Slava
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170119/e97208e7/attachment.html>