Hmm, when we cast from an existential type to a non-existential type (i.e. a concrete type), we check if that type we're casting to conforms to the protocol or not. Dictionary conforms to Encodable when Key and Value conform to Encodable. However, here the Value is Encodable and Encodable does not conform to itself and hence [String: Encodable] does not conform to Encodable, so I can see why the typechecker would think that this cast would fail, as it does not know that you're passing in a value of type [String: String] at call site which does conform to Encodable.

In the meantime, what you can do is something like this:

func encodableCast<T: Encodable>(_ e: T) {
  let f = e as? [String: Encodable]
  print(f?.description ?? "nil")
}

which should avoid triggering that warning.

cc @xedin @hborla

@theblixguy I can see what you are saying about Encodable not conforming to Encodable. If that is the case though how come the cast works when I run the code.

The full version of the code is actually based on a function from the JSONEncoder in swift-corelibs-foundation (https://github.com/apple/swift-corelibs-foundation/blob/d492e580e9c1fc6491087f96dca896e4412eb138/Foundation/JSONEncoder.swift#L889).

I was talking from the typechecker's perspective, not the runtime. What it's trying to do is check if [String: Encodable] conforms to Encodable or not. As explained above, it doesn't and hence the warning.

@theblixguy Well the bug is really about the typechecker and the runtime disagreeing.

Yeah, I agree. I’m not sure what the best solution is - we can change the wording of the diagnostic to say that the cast “might/may fail” instead of “always fails”, we can add more special cases or we can remove the check completely (which would be a bit of a loss as it’s quite helpful in a lot of cases).

@swift-ci create

@theblixguy I guess in positions like this (key, value type of the dictionary or element type of a collection) it's safe to assume that `Key`, `Value` is a value of protocol type which would be substituted to the correct type in the runtime? I think it make sense for conformance check in such cases to allocate archetype and add a conformance to it just like we do in constraint system for elements of the collection. Overall I think it would be best to move all such checks into constraint system and check while search for solution instead of post-application.

This is fixed on master, @adam-fowler can you please verify on the next available snapshot and close? Thanks 🙂

verified