3 ms·

There's no reason for "throws" to be there neither, that's what I mean by these small mistakes adding up. If there was an argument that actually made sense, I'

• favorited 6y ago
  The fact that you personally dislike something does not make it a mistake.
  • onelovetwo 6y ago
    Well you can instantly tell its an async func, and it reads like english when reading it. Why do you think this would be a mistake? I'm just looking for a decent reasoning.
    • favorited 6y ago
      Since Swift strives for clarity at the call-site, you will definitely still have that property. Readers will know it's async because it will say `let x = await loadContent()` (the same way they know it could return an error because it has to start with `try`). If, rather, you're looking at the function definition, you already need to read the whole thing. You need to read what the parameters are, whether or not it throws, what its return type is, etc. So putting the effects (like throwing or async) after the name makes it IMO much more scannable. Because the first thing I want to know is the name. I only care about those implementation details once I know I'm looking at the right thing. There's also no universal consistency between languages. Rust put `.await` after the function invocation rather than as a prefix keyword. C++ used `co_async` and `co_await` as the keywords to avoid breaking lots of people's code. Swift should put the keyword where it makes sense from a consistency standpoint with Swift, which in this case is with `throws`.
  • breakfastduck 6y ago
    A fact sorely unappreciated by a lot of engineers.