5 ms·

In this particular case, adding an explicit type didn’t help at all. I’ve worked in a large Swift project with those timeout warnings enabled, and didn’t find

In this particular case, adding an explicit type didn’t help at all. I’ve worked in a large Swift project with those timeout warnings enabled, and didn’t find them too helpful. They showed up a lot and it was rarely obvious how to quickly fix them. Possibly it would have been useful if those warnings were enabled from the start and developers had always fixed them proactively. I’m skeptical that that could work in a big fast-moving team project, though.

danpalmer 3y ago
I think it's reasonable to have a warnings-are-errors approach even in medium sized teams, or if not quite that approach perhaps a "warnings go in the bug tracker" approach. I'm far from a Swift expert, but I usually found I could reduce the compilation time with ~10 mins of work. When I turned these on for a small codebase (60k lines, ~50% of an engineer split across 3 people), it only took a few hours to solve all the instances of this, and they were mostly obvious cases where a 100 line function could be split into 3 and solve the issue.
- addaon 3y ago
  Warnings-as-errors is a great policy in general, but these are non-deterministic warnings based on compile time wall timing. Coworker working on a slower computer than you? He can run into hundreds of errors after a pull that you introduced but couldn't see, what now? Running something intensive in the background? You can't compile successfully any more. Not ideal.
  - danpalmer 3y ago
    That's true, but a setting of 100ms is a few orders of magnitude higher than expressions should be so it's quite possible to make this fairly reliable.
    - addaon 3y ago
      The problem is that if this ever catches anything, then there's things that it almost catches. And you have no way of telling if you have something expression that takes 99 ms on your machine, so will take 101 ms on your coworkers'. The appropriate way to deal with this in general is to have separate warning and error thresholds, where the difference between the two is greater than the variance between machines, e.g. 50 ms and 100 ms; at least in this case when your coworker checks out a broken build he can see that warnings were introduced in your commit in a CI build log and track it down to the source.
      - danpalmer 3y ago
        It's easy to have one setting for local development and one for CI. Xcode supports different profiles natively so you can just put 50ms or whatever in your user settings and leave 100ms or even 1s in your standard build settings. Also, this sort of works the other way too. Just because something failed at the 100ms threshold doesn't mean it would complete in 101ms, it might take 500ms, 10 minutes, or be undecidable, and it's important to fail CI in those sorts of cases to protect other developers from issues, so having a limit is useful even if it's relatively high for the default case.
        addaon 3y ago
        I guess I don't see what the actual workflow is supposed to be for a new team member who joins (potentially with a different computer than everyone else), checks out the code, and has dozens of errors when they first try to build. I'm a huge fan of error'ing on warnings, but I really don't see it as appropriate for nondeterministic cases.

danpalmer 3y ago

I think it's reasonable to have a warnings-are-errors approach even in medium sized teams, or if not quite that approach perhaps a "warnings go in the bug tracker" approach. I'm far from a Swift expert, but I usually found I could reduce the compilation time with ~10 mins of work. When I turned these on for a small codebase (60k lines, ~50% of an engineer split across 3 people), it only took a few hours to solve all the instances of this, and they were mostly obvious cases where a 100 line function could be split into 3 and solve the issue.

addaon 3y ago
Warnings-as-errors is a great policy in general, but these are non-deterministic warnings based on compile time wall timing. Coworker working on a slower computer than you? He can run into hundreds of errors after a pull that you introduced but couldn't see, what now? Running something intensive in the background? You can't compile successfully any more. Not ideal.
- danpalmer 3y ago
  That's true, but a setting of 100ms is a few orders of magnitude higher than expressions should be so it's quite possible to make this fairly reliable.
  - addaon 3y ago
    The problem is that if this ever catches anything, then there's things that it almost catches. And you have no way of telling if you have something expression that takes 99 ms on your machine, so will take 101 ms on your coworkers'. The appropriate way to deal with this in general is to have separate warning and error thresholds, where the difference between the two is greater than the variance between machines, e.g. 50 ms and 100 ms; at least in this case when your coworker checks out a broken build he can see that warnings were introduced in your commit in a CI build log and track it down to the source.
    - danpalmer 3y ago
      It's easy to have one setting for local development and one for CI. Xcode supports different profiles natively so you can just put 50ms or whatever in your user settings and leave 100ms or even 1s in your standard build settings. Also, this sort of works the other way too. Just because something failed at the 100ms threshold doesn't mean it would complete in 101ms, it might take 500ms, 10 minutes, or be undecidable, and it's important to fail CI in those sorts of cases to protect other developers from issues, so having a limit is useful even if it's relatively high for the default case.
      - addaon 3y ago
        I guess I don't see what the actual workflow is supposed to be for a new team member who joins (potentially with a different computer than everyone else), checks out the code, and has dozens of errors when they first try to build. I'm a huge fan of error'ing on warnings, but I really don't see it as appropriate for nondeterministic cases.