"unable to type-check this expression in a resonable time"

Evolution Discussion
1

My understanding is that this error is a consequence of a combination of ad-hoc polymorphism + bidirectional (constraint-based) type checking. (please correct me if I'm wrong)

What would Swift lose w/o the constraint-based type checker? The concise enum syntax? what else? Could SwiftUI still work?

This is a technical question. I don't want to litigate whether a change should be made.

1 Like
2

Inferring closure signature would be affected. Worst case scenario you would need to spell out entire signature, which would make usages of SwiftUI more verbose. But technically it would still work.

3

Ah interesting. So I'd have to do something like:

GeometryReader { cx: GeometryProxy in 
   ...
}

instead of omitting the GeometryProxy.

Would I ever have to spell out the massive types that SwiftUI builds up? That would be impossible.

Also, C++ doesn't use constraint-based checking AFAIK, but you can still omit types for lambdas... I suppose that's because they're made into templates, which wouldn't work with Swift.

So I guess you'd also have to spell out types when doing simple things like map:

[1,2,3].map { x: Int in x*2 }

and there goes the concise $0 syntax, right?

4

Yes. But that’s a worse case scenario. Maybe more knowledgeable people can give a more optimistic estimate.

C++ lambdas with auto arguments have templated operator(), so they don’t really have a signature until they are called. And if they are called from multiple places, each call site can have its own signature. During Template argument deduction function body does not affect the result, but is type checked after. In Swift function body is also taken into account.

1 Like