4 ms·
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 decen
by 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 agoSince 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`.