top | item 40662986

(no title)

ash_gti | 1 year ago

Your example is different than the example in the post.

Specifically, `channel = 11`, an integer.

If it was a string then it parses very quickly.

discuss

order

mrkeen|1 year ago

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

ash_gti|1 year ago

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.