Comment by Jacob G (JIRA)

It also seems to only happen when using foo.bar. I would have said that this might be intentional if it also occurred when foo was defined as a constant.

Comment by Haris Amin (JIRA)

Can we close/resolve this issue? Running the attached `main.swift` now on 3.0.1 and 3.0.2 properly throws exception.

main.swift:11:20: error: '.dynamicType' is deprecated. Use 'type(of: ...)' instead
debugPrint(foo.bar!.dynamicType) // _dynamicType.Bar
^~~~~~~~~~~~
type(of: )
main.swift:11:19: error: value of type 'Bar' has no member 'dynamicType'
debugPrint(foo.bar!.dynamicType) // _dynamicType.Bar
~~~~~~_{^ ~}~~~~~~~~~

Comment by John Regner (JIRA)

The result you are seeing harisamin (JIRA User) is because dynamicType has been removed and replaced with the type(of: T) function.

I think the question here is "What is the expected behavior?".

In the sample code above the code intends to check/print the runtime type of a property on a struct. In my opinion, the behavior you are seeing is the correct behavior.

I've found the implementation in swift/stdlib/public/core/Builtin.swift

Looks like this is resolved by the "type checker", I'm guessing that there is no effort to "unwrap" the value that would result in the "Unexpectedly found nil" that you are expecting.

/// - Parameter value: The value to find the dynamic type of.
/// - Returns: The dynamic type, which is a value of metatype type.
@_transparent
@_semantics("typechecker.type(of:)")
public func type<T, Metatype>(of value: T) -> Metatype {
  // This implementation is never used, since calls to `Swift.type(of:)` are
  // resolved as a special case by the type checker.
  Builtin.staticReport(_trueAfterDiagnostics(), true._value,
    ("internal consistency error: 'type(of:)' operation failed to resolve"
     as StaticString).utf8Start._rawValue)
  Builtin.unreachable()
}

Suggest to close, works as expected.

john_regner (JIRA User) Although calls to type(of:) are handled as a special case by the type checker, they should still have the semantics of a function call; as the functionality is exposed to developers in the form of a function, rather than a special expression like #type(...). Therefore, the argument expression passed to it should be evaluated (and therefore crash) IMO.

The first example has actually already been fixed (accidentally, I think) by #14299, as when coercing the lvalue to an rvalue for the call argument to type(of:), the force unwrap is separated from the lvalue (i.e the lvalue x is loaded, then force unwrapped), therefore bypassing the logic in emitIgnoredExpr to avoid loading.

Though it seems a shame a load has to actually be performed here, rather than just getting the address, which is what I believe could've happened if the force unwrap component was a part of the lvalue and we fixed the side effect logic.

The side effect logic still needs fixing in the general case though.

#14410