5 ms·
could you imagine having a function with many arguments and trying to find the async. internal func refreshPlayers(firstParameter: String, secondParameter: Int
by onelovetwo 6y ago
could you imagine having a function with many arguments and trying to find the async.
internal func refreshPlayers(firstParameter: String, secondParameter: Int, thirdParameters: Float) async {
}
these small mistakes are starting to add up with Swift. They should really nip these things in the butt instead of adding upon the inconsistencies. Its better to make bold decisions now that you know is right than to change them 10 years from now when everyone is already use to them, which is what some older languages are dealing with now.
Why not just have it be async func refreshPlayers() { }
- andrewbarba 6y agoThat's like saying: Could you imagine having a function with many arguments and trying to find the return type? Swift already uses the space at the end of the function declaration for things like throw and generic constraints. I personally don't see an issue with where it is other than I also write a lot of JavaScript and the context switching between languages might take a couple seconds.
- onelovetwo 6y agoThere'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'd understand, but there is none. this is the argument: (https://forums.swift.org/t/swift-concurrency-roadmap/41611/9 https://forums.swift.org/t/swift-concurrency-roadmap/41611/9)
- favorited 6y agoThe fact that you personally dislike something does not make it a mistake.
- onelovetwo 6y agoWell 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`.
- breakfastduck 6y agoA fact sorely unappreciated by a lot of engineers.
- rcstank 6y agoNip in the bud, not butt. It means to cut off the bud (i.e. flower bud) before it grows into something larger.
- onelovetwo 6y agoI meant what I said lol
- myko 6y agoI agree that it feels like the language maintainers are backed into corners and cannot correct old mistakes. Which feels strange coming from Apple. Google showed up to use this with Go, write a tool that updates the code from version "x" to version "y" instead of being beholden to source compatibility issues in situations like this.
- zepto 6y agoXCode has had code updating for years.
- myko 6y agoTrue, it has something like that (which works to varying levels of success depending on the project). The excuse for not fixing weird syntax oddities like this though is breaking source compatibility, which my point was tooling should solve. Essentially the tooling in the Apple ecosystem is rough to work with and feels poorly thought out - it feels like the teams work independently and then mash their stuff together right before go live.
- zepto 6y agoTrue, but compared to what? Everyone else seems just as bad in that regard.
- jamiek88 6y agoNip in the bud.