Why can't I pass an implicitly unwrapped optional as an UnsafeMutablePointer?

问题

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.

回答1:

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