why does guard break type inference?

Question

I have met a problem like what title has described: the guard statement breaks type inference for some reason. I have created a Playground project to play around.

Here are some boilerplate code for setup:

import Foundation

struct Model: Decodable {
    var i: String
}

let jsonString = """
{
    "i": "yes"
}
"""

let jsonData = jsonString.data(using: .utf8)
let theModel = try JSONDecoder().decode(Model.self, from: jsonData!)

struct Response<T> {
    var decodedData: T?
}

enum Result<Value> {
    case success(Value)
    case failure
}

struct Client {
    static let shared = Client()
    private init() {}

    func execute<T: Decodable>(completion: (Response<T>) -> ()) {
        let decodedData = try! JSONDecoder().decode(T.self, from: jsonData!)
        completion(Response(decodedData: decodedData))
    }
}

Here's the problem:

struct ServicesA {
    func loadSomething(completion: (Result<Model>) -> ()) {
        Client.shared.execute { result in      // error: generic parameter 'T' could not be inferred
            guard let decodedData = result.decodedData else { return }
            completion(Result.success(decodedData))
        }
    }
}

struct ServicesB {
    func loadSomething(completion: (Result<Model>) -> ()) {
        Client.shared.execute { result in
            completion(Result.success(result.decodedData!))
        }
    }
}

ServicesA breaks whereas ServicesB compiles.

As what you can see, the only difference is guard let decodedData = result.decodedData else { return }. It breaks the type inference so that the Client.shared.execute function complains that the T can't be inferred.

I wonder why would this happen and what's the most appropriate way to deal with this issue.

`guard let decodedData = data else { return }` should be `guard let decodedData = result.decodedData else { return }` — Prashant Tukadiya, May 31 '18 at 13:07
Compare https://stackoverflow.com/q/42213656/2976878 – closures only participate in type inference when they contain a single statement. — Hamish, May 31 '18 at 13:49
@PrashantTukadiya yeah thanks, that was a typo when I am editing into stackoverflow. But my program was in the right format. Just edited my question. — Tony Lin, May 31 '18 at 14:08

Aamir · Accepted Answer · 2018-05-31T23:17:55.773

TLDR; single line closure compilation is different from multi line

Long answer: Let’s forget single line closures for sometime. When we write generic function accepting a generic as argument type and then call this function, compiler needs to know at time of invocation about what’s the type of function needed i.e. the type of its argument. Now consider this argument is a closure. Again compiler needs to know what’s the type of closure (function signature) at time of invocation. This info should be available in the signature of the closure (i.e. argument and return type), compiler doesn’t worry (and rightly so) about the body of the closure. So Service A is behaving perfectly as expected from compiler i.e. the closure signature doesn’t give any clue of its type.

Now comes in single line closure. Swift compiler has a built in type inference optimisation for single line closures only. When you write single line closure, compiler first kicks in its type inference and try to figure out about the closure including its return type etc from its only single line of body . This type inference kicks in for single line closures (with or without the context of generics). This type inference is the reason that your service B works

So I’ll rephrase the question as “Why does the type inference works for single line closures?” because that’s an extra feature provided by Swift for single line closures only. As soon as you move to multi line closure (its not guard statement specific, same will happen if you put print(“hello world”) as well), this type inference is no more available. Though there may be other type inference checks available for multi line closures.

What you can do is just provide the Type info in closure signature i.e (result: Response< Model >)

Your answer is better-worded than mine, but you should write "statement", not "line". Swift statements may be broken up across lines. — Avi, Jun 01 '18 at 03:16

Avi · Answer 2 · 2018-06-01T03:21:48.003

3

The compiler only infers closure return types when there is a single statement in the closure.

let x = {
    return 1
}()

                // x == Int(1)

let y = {       // error: unable to infer complex closure return type; add explicit type to disambiguate
    print("hi")
    return 2
}()

https://forums.swift.org/t/problems-with-closure-type-inference/11859/2

edited Jun 01 '18 at 03:21

answered May 31 '18 at 13:36

Avi

7,469
2
21
22

This is very interesting, but the error seems to be different to mine. They seem complaining about different thing? – Tony Lin May 31 '18 at 14:15
Yours involves generics, and I guess the compiler is complaining about that first. – Avi May 31 '18 at 15:20
actually this is the correct answer, could you provide any reference? – Tony Lin May 31 '18 at 23:45
I think I saw this as a comment on the official Swift Forums. I'll try and dig up a link. – Avi Jun 01 '18 at 03:16

vicegax · Answer 3 · 2018-05-31T13:27:11.690

0

Problem is you are referencing data variable but the compiler doesn't know what type is this (because it is a Generic). Try this:

struct ServicesA {
    func loadSomething<T:Model>(completion:(Result<T>) -> ()) {
        Client.shared.execute { result:Response<T> in
            guard let decodedData = result.decodedData else { return }
            completion(Result.success(decodedData))
        }
    }
}

edited May 31 '18 at 13:27

answered May 31 '18 at 13:18

vicegax

4,709
28
37

could you explain why `ServicesB` won't have this issue if I don't cast the type? – Tony Lin May 31 '18 at 14:14
@TonyLin Because in `ServicesB` the compiler doesn't need to know the type of `Model` you are using. The type of `Model` will be defined by the users of `ServicesB`, that is, in the implementation, i.e. when you call `loadSomething` and assign `completion`. `ServicesA` is different, here you will need to define `Model` in the implementation too, but the type of `Model` is not transparent for `ServicesA` as you are making a reference to it (the guard). – vicegax May 31 '18 at 14:29
why making a reference to it (the guard) will lose the type inference? – Tony Lin May 31 '18 at 14:35
Because you can't infer a type that is defined out of the scope. Here by using Generics you are allowing this type to be defined in another class. Basically the guard is **not** "breaking the type inference", rather `ServicesB` is not trying to infer the type, that is why it works there. – vicegax May 31 '18 at 14:41

score 0 · Answer 4 · answered May 31 '18 at 13:24

0

You need to type cast it result with Result< Model > so can compiler know about T

struct ServicesA {
    func loadSomething(completion:(Result<Model>) -> ()) {
        Client.shared.execute { (result:Response<Model>) in
            guard let data = result.decodedData else {return}
            completion(Result.success(data))
        }
    }
}

answered May 31 '18 at 13:24

Prashant Tukadiya

15,838
4
62
98

can you explain why I need to cast it when I have the `guard` statement? I don't need to cast it when I don't use `guard` as my example given, namely `ServicesB` class. – Tony Lin May 31 '18 at 14:13

why does guard break type inference?

4 Answers4