> On Jan 19, 2017, at 10:52 PM, rintaro ishizaki via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
