4 ms·
I actually don't mind that feature too much. I do appreciate that it clarifies code with even a few arguments of the same type. Although there are other ways to
by geophile 7y ago
I actually don't mind that feature too much. I do appreciate that it clarifies code with even a few arguments of the same type. Although there are other ways to clarify such situations in other languages. The Swift approach does lead to exceptionally verbose code, but that's obviously subjective.
It's the $n syntax that I think is overkill. Do we really need three different ways to name parameters?
- skohan 7y agoYeah to each her own I guess, but I don't mind the $n syntax either. It's only relevant in closures, and in my experience it's mostly used in simple, short closures where the identity of the parameter is obvious. So for example if you are doing a simple map: let incremented = myArray.map { $0 + 1 } the $n syntax just lets you save a little bit of typing. In my opinion it often makes the intent clearer when reading a line of code, since having to explicitly name the variable here adds noise which isn't really meaningful, especially in the case where you have a chain of map/reduce/filter operations. I would put it in the same category as Rust's `?` operator, which saves you from typing a bunch of unwraps or match statements everywhere.
- tonyedgecombe 7y agoI assumed it was there for compatibility with Objective-C, I can't imagine any other justification.
- skohan 7y agoWhat would it have to do with Objective-C?
- tonyedgecombe 7y agoBecause objective-c has the same feature, if you want seamless integration with existing libraries then you need it.