It seems that Xcode 9.3 does fix one issue I was having, but in Swift 4.1 the second half of this code still doesn't compile:
var obj: SomeClass! ; class SomeClass {}
func inoutFunc(_: inout SomeClass?) {}
inoutFunc(&obj) // works
func pointerFunc(_: UnsafeMutablePointer<SomeClass?>) {}
pointerFunc(&obj) // <-- COMPILER ERROR
The call to inoutFunc
is now fine, but the call to pointerFunc
still gives me an error:
Cannot invoke 'pointerFunc' with an argument list of type '(inout SomeClass!)'
Or in the original context:
Cannot pass immutable value of type 'ActualClass?' as inout argument
Similar to my Swift 4.0 issue (where the inoutFunc
didn't compile either) if I change the declaration to var obj: SomeClass?
then the second function call compiles without complaint.
Is this another lingering Swift bug related to Implicitly Unwrapped Optionals, or would this UnsafeMutablePointer
situation not be expected to work like the inout
version now does? Is there a relatively clean workaround?
Background:
In the actual code, the pointerFunc
call is an Apple framework function which either initializes the instance or returns an error status.
Since I already guard AppleFrameworkInitializer(&obj) == noErr else { /* … */ }
, I don't want to deal with re-assigning from a temporary optional, or have to constantly unwrap obj!
in all the code that follows.
That is, this seems like a legitimate use case for Implicitly Unwrapped Optionals and I'm wondering why I still can't use one here.
I'm afraid this is another lingering bug around implicitly unwrapped optionals (IUOs).
It has already been fixed though (almost certainly as a result of the recent-ish work to completely remove IUOs from the type system) – it compiles in the latest dev snapshots, and therefore will make it into 4.2 (final re-branch from master is April 20).
Until 4.2 rolls around, one possible workaround would be to use a forwarding computed variable in order to treat the IUO as a strong Optional type:
class SomeClass {}
var obj: SomeClass!
var _optionalObj: SomeClass? {
get { return obj }
set { obj = newValue }
}
func pointerFunc(_: UnsafeMutablePointer<SomeClass?>) {}
pointerFunc(&_optionalObj)
(that is, assuming you're okay with having the pointer point to a temporary value – i.e you're not relying on the pointer value being stable or unique, such as you would be if this were to be used, for example, as an associated object key)
来源:https://stackoverflow.com/questions/49928472/why-cant-i-pass-an-implicitly-unwrapped-optional-as-an-unsafemutablepointer