5 ms·

Maybe I'm too old school but the removal of for loop is quite surprising. for-in doesn't tell you the index of the current object so you'd have to manually kee

Maybe I'm too old school but the removal of for loop is quite surprising. for-in doesn't tell you the index of the current object so you'd have to manually keep track of the index. Also, x++ is a common syntax in many languages and I think a new developer looking at Swift would try that first before using the other syntax (x += 1).

fauigerzigerk 10y ago
I think what a new developer would try first isn't a particularly good yardstick for language design. But I also think that the removal of ++ causes some problems. For instance, now I have this code mutating func next() -> Element? { //... pos += 1 return data[pos-1] } or alternatively mutating func next() -> Element? { //... let e = data[pos] pos += 1 return e } where previously I had mutating func next() -> Element? { //... return data[pos++] }
- chrisamanse 10y ago
  IMHO, ++ is not readable. A beginner would think that data[pos++] is the same as data[pos+1] when it's actually, data[pos]; pos = pos + 1;.
  - fauigerzigerk 10y ago
    I don't care what beginners might think. I care about the mental load for professional developers. Beginners can learn.
    - kartickv 10y ago
      A beginner should be made to learn something only if they get an advantage out of it in readability or type safety or performance or something else. I don't see that being the case for pre- and post-increment. If anything, I find: i += 1; String name = names[i]; more readable than String name = names[++i]; where I have to pause and remind myself of pre- and post- increment and which one is being used here and mentally translate the code into the above version. Imperative languages already have a way of specifying execution order: it's the order of statements in your file. Let's reuse that rather than making things more complex.
      - felixgallo 10y ago
        In your list of things that beginners must get an advantage out of, you left out functionality and brevity. Hope that helps.
        kartickv 10y ago
        I don't see a difference in functionality — both code snippets I gave do exactly the same thing. As for brevity, I think clarity is more important. We should optimise for the time it takes to read and understand the code (clarity), not just read (brevity). The best abstractions and programming language features are both brief and clear, like Python's list comprehensions. I find [name.uppercase() for name in names if name.startswith("a")] to be clearer than Java's List<String> uppercaseNames = new ArrayList<>(); for (String name: names) { if (name.startsWith("a")) uppercaseNames.add(name.toUpperCase()); } So, the best programming language features enhance both brevity and clarity. When that's not possible, I'll take slightly longer but clearer code over short but confusing one.
    - danneu 10y ago
      I've seen ++i vs i++ cause so many bugs that whenever I see it, I stop to ponder if the author got it right. It's like in Javascript where I stop to check if the author intended for `if (x)` to take the false path if x is "" and 0. It's death by a thousand papercuts for my mental load.
  - stevetrewick 10y ago
    IMHO ++ is trivially readable, but that's only because I happen to be familiar with C/C++'s pre/post increment idiom. An idiom which is well known for causing confusion and bugs, especially - as you say - for devs new to the language. For me the compelling argument for removing them is that they're a Cism and don't fit with the semantics of any of the other operators. Chris Lattner strongly agrees with you and explains his reasons here https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md https://github.com/apple/swift-evolution/blob/master/proposa...
- jayrhynas 10y ago
  FYI, a third option is mutating func next() -> Element? { //... defer { pos += 1 } return pos } Whether it's better is a matter of opinion
  - stevetrewick 10y ago
    Nice. That's a beautifully idiomatic implementation of the original intent of post increment, if nothing else.
  - jayrhynas 10y ago
    I just realized there's a small typo in the above, it should be return data[pos]
lukeholder 10y ago
You have access to the index in a for-in: for (index, element) in list.enumerate() { print("Item \(index): \(element)") }
- stevetrewick 10y ago
  Nitpick: for...in is not providing access to the index, it's the enumerate() method returning a collection of tuples, the first element of which happens to be an index.
- jathu 10y ago
  for-in is elegant, and you can use enumerate() to access index. However, if we had to do reverse for-loops in Swift 3, we would have to use for-in with either from.stride(to:by:) or reverse(), and to me that is not as elegant as c style for loops.
  - masklinn 10y ago
    Interesting, it feels significantly more elegant to me as you're simply telling the language what you want (reverse iteration) and it handles the exact details, and works for any reversible iterable.
masklinn 10y ago
> for-in doesn't tell you the index of the current object so you'd have to manually keep track of the index. Functional decoration trivially provides that. Just zip a counter with the backing iterable, and modern languages generally provide that OOTB as a variant of `enumerate()` e.g. for i, item in it.enumerate(): # stuff > Also, x++ is a common syntax in many languages Meh. It's generally present in B derivatives (via C) and that's pretty much it. Most languages do just fine without it.
- deleted 10y ago
  [deleted]

fauigerzigerk 10y ago

I think what a new developer would try first isn't a particularly good yardstick for language design. But I also think that the removal of ++ causes some problems. For instance, now I have this code mutating func next() -> Element? { //... pos += 1 return data[pos-1] } or alternatively mutating func next() -> Element? { //... let e = data[pos] pos += 1 return e } where previously I had mutating func next() -> Element? { //... return data[pos++] }

chrisamanse 10y ago
IMHO, ++ is not readable. A beginner would think that data[pos++] is the same as data[pos+1] when it's actually, data[pos]; pos = pos + 1;.
- fauigerzigerk 10y ago
  I don't care what beginners might think. I care about the mental load for professional developers. Beginners can learn.
  - kartickv 10y ago
    A beginner should be made to learn something only if they get an advantage out of it in readability or type safety or performance or something else. I don't see that being the case for pre- and post-increment. If anything, I find: i += 1; String name = names[i]; more readable than String name = names[++i]; where I have to pause and remind myself of pre- and post- increment and which one is being used here and mentally translate the code into the above version. Imperative languages already have a way of specifying execution order: it's the order of statements in your file. Let's reuse that rather than making things more complex.
    - felixgallo 10y ago
      In your list of things that beginners must get an advantage out of, you left out functionality and brevity. Hope that helps.
      - kartickv 10y ago
        I don't see a difference in functionality — both code snippets I gave do exactly the same thing. As for brevity, I think clarity is more important. We should optimise for the time it takes to read and understand the code (clarity), not just read (brevity). The best abstractions and programming language features are both brief and clear, like Python's list comprehensions. I find [name.uppercase() for name in names if name.startswith("a")] to be clearer than Java's List<String> uppercaseNames = new ArrayList<>(); for (String name: names) { if (name.startsWith("a")) uppercaseNames.add(name.toUpperCase()); } So, the best programming language features enhance both brevity and clarity. When that's not possible, I'll take slightly longer but clearer code over short but confusing one.
  - danneu 10y ago
    I've seen ++i vs i++ cause so many bugs that whenever I see it, I stop to ponder if the author got it right. It's like in Javascript where I stop to check if the author intended for `if (x)` to take the false path if x is "" and 0. It's death by a thousand papercuts for my mental load.
- stevetrewick 10y ago
  IMHO ++ is trivially readable, but that's only because I happen to be familiar with C/C++'s pre/post increment idiom. An idiom which is well known for causing confusion and bugs, especially - as you say - for devs new to the language. For me the compelling argument for removing them is that they're a Cism and don't fit with the semantics of any of the other operators. Chris Lattner strongly agrees with you and explains his reasons here https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md https://github.com/apple/swift-evolution/blob/master/proposa...
jayrhynas 10y ago
FYI, a third option is mutating func next() -> Element? { //... defer { pos += 1 } return pos } Whether it's better is a matter of opinion
- stevetrewick 10y ago
  Nice. That's a beautifully idiomatic implementation of the original intent of post increment, if nothing else.
- jayrhynas 10y ago
  I just realized there's a small typo in the above, it should be return data[pos]

lukeholder 10y ago

You have access to the index in a for-in: for (index, element) in list.enumerate() { print("Item \(index): \(element)") }

stevetrewick 10y ago
Nitpick: for...in is not providing access to the index, it's the enumerate() method returning a collection of tuples, the first element of which happens to be an index.
jathu 10y ago
for-in is elegant, and you can use enumerate() to access index. However, if we had to do reverse for-loops in Swift 3, we would have to use for-in with either from.stride(to:by:) or reverse(), and to me that is not as elegant as c style for loops.
- masklinn 10y ago
  Interesting, it feels significantly more elegant to me as you're simply telling the language what you want (reverse iteration) and it handles the exact details, and works for any reversible iterable.

masklinn 10y ago

> for-in doesn't tell you the index of the current object so you'd have to manually keep track of the index. Functional decoration trivially provides that. Just zip a counter with the backing iterable, and modern languages generally provide that OOTB as a variant of `enumerate()` e.g. for i, item in it.enumerate(): # stuff > Also, x++ is a common syntax in many languages Meh. It's generally present in B derivatives (via C) and that's pretty much it. Most languages do just fine without it.

deleted 10y ago
[deleted]