51–60 of 364 posts
Earlier quoted context omitted.
Indeed a clear syntax. OTOH, a "loop .. for .. {upto, below} count" leaves less questions in a casual code review :)
I prefer explicit words over symbols, like in Scala: scala> 1 to 3 scala.collection.immutable.Range.Inclusive = Range(1, 2, 3) scala> 1 until 3 scala.collection.immutable.Range = Range(1, 2)
Earlier quoted context omitted.
When I see "0..n" I wonder whether the range is inclusive or exclusive of n. When I see "0..<n" I know the range is exclusive of n.
Yes, but the corresponding design decision would be "0..=n". Swift's "0...n" is a bit less obvious. Also, exclusivity is almost always what you want, so "0..n" should just default to exclusivity and "0...n" could be inclusive.
http://stackoverflow.com/questions/9690801/difference-betwee...
I always remembered it as "the third dot makes it bigger so it pushes the range and the last item falls off". I can't remember where that came from, perhaps related to the poignant guide:
http://poignant.guide/book/chapter-3.html#section2
I actually find in practice the swift ranges are the only ones I can reliably use without having to stop and look up the reference syntax every time.
For some reason, for me, `0..Then I can work from there and if it doesn't have the I suspect `0..=n` would work similarly well, but I've not seen a real language to ever do that yet
Earlier quoted context omitted.
Swift has both external and internal parameter names for functions. This is to make API design more readable, easier to parse through. For example, you can have a function like so: func greet(with greeting: String, to personName: String) { print("\(greeting), \(personName)!") } In the above code, "with" and "to" are external names, and are only available when calling the function but are not available inside the func…
Having never used Swift, it feels like the syntax is being optimized for the less-common case; are named parameters considered the "default" choice in Swift, and is using different external names so common that it's worth cluttering the syntax for functions without external parameters in order to make the their own syntax easier?
-(void) greetWith:(NSString *)greeting to:(NSString *)personName
[self greetWith:@"Hello" to:@"Bob"]
Could someone tell me the meaning of _ in this Swift code: func greet(_ name: String,_ day: String) -> String { return "Hello \(name), today is \(day)." } greet("Bob", "Tuesday") In me prior experience usually _ denoted an unused parameter/variable. Also: I find the string interpolation syntax ugly... The syntax choices in Swift are curious, but not the most aesthetical/practical in my opinion.
Swift has both external and internal parameter names for functions. This is to make API design more readable, easier to parse through. For example, you can have a function like so: func greet(with greeting: String, to personName: String) { print("\(greeting), \(personName)!") } In the above code, "with" and "to" are external names, and are only available when calling the function but are not available inside the func…
Earlier quoted context omitted.
What do you like about it? I was actually thinking the opposite... EDIT: Genuinely curious, this is not meant to troll or start a war. I like the more explicit feeling `count-1`. I'd use either...
In the early beta release of Swift 0.x, they used x..y for half-open ranges and x...y for closed ranges. This confused people (especially since Ruby already used the same operators but the other way around), so they changed the half-open operator to x..<y.
Earlier quoted context omitted.
Swift has both external and internal parameter names for functions. This is to make API design more readable, easier to parse through. For example, you can have a function like so: func greet(with greeting: String, to personName: String) { print("\(greeting), \(personName)!") } In the above code, "with" and "to" are external names, and are only available when calling the function but are not available inside the func…
I think it likely that labeled arguments were introduced mainly for Objective-C interoperability.
For the first versions of Swift, they actually had two versions. For functions (i.e not functions inside classes), you didn't have to have named arguments for the first parameter, but you did for methods (functions inside classes).
They explicitly added it for Swift 3 to make it more consistent with method.
I think I like the consistency more, but I do agree "_" is ugly. I don't have an idea of what else they could do though. I don't want Swift to make the parameter names optional, since no one would use it (like in Python, I rarely see named arguments being used)
Syntax should be a personal preference, installable module built on a standardized AST which compiles to whatever VM.
I like swift's conditionals without brackets, OTOH the syntax for string interpolation is ugly
Ugh, I know it's something that literally every programmer on earth can and often does bikeshed, but Swift just got string interpolation syntax wrong . Parentheses are something that are often part of the interpolated expression... they shouldn't be part of the interpolation syntax itself.
Swift's string interpolation doesn't catch my eye like, say, Ruby's does: `#{my_var}`. It's very easy to gloss over `\(something_like_this)`. I suspect they were going for a more "elegant" syntax at the cost of pragmatism.
val oneInch = 2.54.mm println("One inch is $oneInch.cm() centimeters")