If what your saying is true (the type is fixed as an integer), then it's even easier in tfa's case. No inference necessary.
In my code channel is not a string, it's one type of the 31-set of (String, Foo01, Foo02, .., Foo30). So it needs to be inferred via HM.
> If it was a string then it parses very quickly.
"Parses"? I don't think that's the issue. Did you try it?
----- EDIT ------
I made it an Int
let channel = 11 :: Int
instance IsString Int where
fromString = undefined
instance Semigroup Int where
(<>) = undefined
real 0m0.543s
user 0m0.396s
sys 0m0.148s
The type is an inferred integer literal in swift (in the swift standard this is the `ExpressibleByIntegerLiteral`, the string literals are `ExpressibleByStringLiteral` types).
The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal.
This is whats causing the type checker to try every possible combination of types implementing the `+` operator, types implementing `ExpressibleByIntegerLiteral` and `ExpressibleByStringLiteral` in the standard library. That combination produces 59k+ permutations without even looking at non-standard library types.
If any of the types in the expression had an explicit type then it would be type checked basically instantly. Its the fact that none of the values in the expression have explicit types that is causing the type checker to consider so many different combinations.
mrkeen|1 year ago
In my code channel is not a string, it's one type of the 31-set of (String, Foo01, Foo02, .., Foo30). So it needs to be inferred via HM.
> If it was a string then it parses very quickly.
"Parses"? I don't think that's the issue. Did you try it?
----- EDIT ------
I made it an Int
ash_gti|1 year ago
The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal.
This is whats causing the type checker to try every possible combination of types implementing the `+` operator, types implementing `ExpressibleByIntegerLiteral` and `ExpressibleByStringLiteral` in the standard library. That combination produces 59k+ permutations without even looking at non-standard library types.
If any of the types in the expression had an explicit type then it would be type checked basically instantly. Its the fact that none of the values in the expression have explicit types that is causing the type checker to consider so many different combinations.