5 ms·

Lots of uses on that thread are suggesting this is some sort of design constraint or tradeoff - but I really am not sure I agree. I understand this might not b

Lots of uses on that thread are suggesting this is some sort of design constraint or tradeoff - but I really am not sure I agree. I understand this might not be a high priority, because it's a somewhat contrived usecase rare to matter in "the real world", but I strongly suspect this must be due to bug(s) in the compiler. I cannot think of a single reason it _has_ to be this way per the design of the language.

layer8 3y ago
Not a bug, but probably a naive algorithm where a more sophisticated algorithm with much lower algorithmic complexity could be used.
danpalmer 3y ago
There are different algorithms for type checking that impose different requirements on users. The Java approach is roughly: write types everywhere, keep them simple (and limited in scope), it's easy for the compiler to infer the types. The Haskell/ML approach is roughly: know a lot about strong type systems, be purely functional, infer most of the types, produce bad error messages when you can't. The Swift approach attempts to be the best of both worlds, lots of inference, strong capabilities in expressing complex types, but the trade-off is that it can't use the inference algorithms of either of the above examples. I believe Swift necessarily has poor time complexity in type checking – it can't be better with the design it has and requirements it puts on authors.
- kaba0 3y ago
  Rust’s type system seems to be ideal in this respect, and is not prone to timing out, so it is likely some design issue with Swift.
  - danpalmer 3y ago
    On the contrary, Rust's type system moves more of that effort on to the developer – there's a reason why Rust has a much steeper learning curve than Swift. The trade-off is a somewhat rare sharp edge for Swift and a much easier onboarding, vs Rusts noticeably harder onboarding and more predictable sharp edges.
    - kaba0 3y ago
      Rust is a low-level language, which requires the dev to track lifetimes as well - that’s the reason it has harder onboarding. It managing an even more complex type system without any of the disadvantages seems to make it clearly great!
manmal 3y ago
Type checking in Swift is notoriously slow and picky. Things have improved over the years (considerably!), but the odd complicated generics usecase will either take a minute extra to compile, or throw a Segfault.
- jodrellblank 3y ago
  Doesn't the link go on to say it's not the type checker causing this? "I found a trace of the compiler kind of surprising; the time is not all being spent in the type checker, as you observed:" - 5th reply by scanon
  - manmal 3y ago
    It says "not all", which I interpret as "some of it is not spent in the type checker". I'm also not sure the times Xcode displays in the screenshot are bound to be accurate.
    - stephencanon 3y ago
      Instruments is a sampling profiler; it's the ground truth w.r.t. where time is being spent.
      - manmal 3y ago
        I don’t know about Instruments‘ implementation, but sampling profilers are not renowned for their accuracy.
        stephencanon 3y ago
        All profiling techniques have their drawbacks, but for a quick "where is the time being spent" analysis at multiple-second granularity, you're solidly in the territory where sampling profilers work really well.
        3y ago
brundolf 3y ago
Anecdote posted as-is: I recently started a macOS app project to learn Swift and SwiftUI. A week or two into the project, I managed to hit an honest-to-god compiler bug. A particular combination of syntaxes would reliably cause the compiler to crash (not yield a compile error; crash). I tried restarting XCode, restarting my computer, updating everything. Whenever I brought that syntax into the editor, XCode's Swift compiler integration would crash. It wasn't anything exotic; I was making a straightforward app, and wasn't trying any Swift language funny-business (I didn't know the language well enough to even try) It was bizarre to so easily find a bug in the headlining compiler made by the world's most valuable company; I can only think it's the result of this being a language that (effectively) only targets one company's systems, and the effect that has on the size and involvement of the community
- napierzaza 3y ago
  [dead]
- jb1991 3y ago
  I think many of us will be really interested to know exactly what syntax you found the crashes it.
  - brundolf 3y ago
    Unfortunately it was several weeks ago and I don't remember or have the code on hand. I think it involved a switch statement in some way
- jitl 3y ago
  I've also hit these kinds of issues with Swift/SwiftUI. It's always surprising for a production compiler to die and throw up it's hands and say "you hit a compiler bug!"

layer8 3y ago

Not a bug, but probably a naive algorithm where a more sophisticated algorithm with much lower algorithmic complexity could be used.

danpalmer 3y ago

There are different algorithms for type checking that impose different requirements on users. The Java approach is roughly: write types everywhere, keep them simple (and limited in scope), it's easy for the compiler to infer the types. The Haskell/ML approach is roughly: know a lot about strong type systems, be purely functional, infer most of the types, produce bad error messages when you can't. The Swift approach attempts to be the best of both worlds, lots of inference, strong capabilities in expressing complex types, but the trade-off is that it can't use the inference algorithms of either of the above examples. I believe Swift necessarily has poor time complexity in type checking – it can't be better with the design it has and requirements it puts on authors.

kaba0 3y ago
Rust’s type system seems to be ideal in this respect, and is not prone to timing out, so it is likely some design issue with Swift.
- danpalmer 3y ago
  On the contrary, Rust's type system moves more of that effort on to the developer – there's a reason why Rust has a much steeper learning curve than Swift. The trade-off is a somewhat rare sharp edge for Swift and a much easier onboarding, vs Rusts noticeably harder onboarding and more predictable sharp edges.
  - kaba0 3y ago
    Rust is a low-level language, which requires the dev to track lifetimes as well - that’s the reason it has harder onboarding. It managing an even more complex type system without any of the disadvantages seems to make it clearly great!

manmal 3y ago

Type checking in Swift is notoriously slow and picky. Things have improved over the years (considerably!), but the odd complicated generics usecase will either take a minute extra to compile, or throw a Segfault.

jodrellblank 3y ago
Doesn't the link go on to say it's not the type checker causing this? "I found a trace of the compiler kind of surprising; the time is not all being spent in the type checker, as you observed:" - 5th reply by scanon
- manmal 3y ago
  It says "not all", which I interpret as "some of it is not spent in the type checker". I'm also not sure the times Xcode displays in the screenshot are bound to be accurate.
  - stephencanon 3y ago
    Instruments is a sampling profiler; it's the ground truth w.r.t. where time is being spent.
    - manmal 3y ago
      I don’t know about Instruments‘ implementation, but sampling profilers are not renowned for their accuracy.
      - stephencanon 3y ago
        All profiling techniques have their drawbacks, but for a quick "where is the time being spent" analysis at multiple-second granularity, you're solidly in the territory where sampling profilers work really well.
        3y ago

brundolf 3y ago

Anecdote posted as-is: I recently started a macOS app project to learn Swift and SwiftUI. A week or two into the project, I managed to hit an honest-to-god compiler bug. A particular combination of syntaxes would reliably cause the compiler to crash (not yield a compile error; crash). I tried restarting XCode, restarting my computer, updating everything. Whenever I brought that syntax into the editor, XCode's Swift compiler integration would crash. It wasn't anything exotic; I was making a straightforward app, and wasn't trying any Swift language funny-business (I didn't know the language well enough to even try) It was bizarre to so easily find a bug in the headlining compiler made by the world's most valuable company; I can only think it's the result of this being a language that (effectively) only targets one company's systems, and the effect that has on the size and involvement of the community

napierzaza 3y ago
[dead]
jb1991 3y ago
I think many of us will be really interested to know exactly what syntax you found the crashes it.
- brundolf 3y ago
  Unfortunately it was several weeks ago and I don't remember or have the code on hand. I think it involved a switch statement in some way
jitl 3y ago
I've also hit these kinds of issues with Swift/SwiftUI. It's always surprising for a production compiler to die and throw up it's hands and say "you hit a compiler bug!"