41–50 of 249 posts
Come on. There are legitimate reasons not to carry one language's expressions to another, but this isn't a good one. Most people first learn of ++/-- as "By the way, you can use ++ as a shortcut to add one" and leave it at that.
I strongly disagree with this. Being able to do a very simple task like increment or decrement a number inline is useful and reduces clutter and I've always found the idea that the operator complicates things ridiculous. The way they work has always been obvious to me since I first learned to program in PHP as a tween.
It looks like they may be trying to make it easier for current tweens that would have otherwise learned PHP.
Don't see the value in this. These operators are terse, well known, and are implemented in a wide array of languages.
Earlier quoted context omitted.
Just having `i += 1` would seem more in line with Go's professed Simplicity philosophy. When both `++i` and `i += 1` mean the same thing, you might as well drop one of them. `++i` (and/or I guess `i++`) is barely syntactic sugar.
i++ is different from i += 1 in this way: += could be i += 2 or i += j or something else. I have to pay attention to be sure. But i++ can only add one.
I could buy the argument if we were dealing with indexes or numbers where you had to read/hunt down occurrences of them to make sure they are what you expect. Like: make sure that a loop with a lot of indexes don't overincrement (out of bounds) or does something else that is wrong. But in this case the space isn't across a method, or a block. The space between the destination (i) and the increment number (1) is literally just 4 characters.
While 4 touches on this a bit, I think another reason is that mutable value types are generally harmful. Save mutability for compiler optimizations and write your code with "let".
You need mutability to write for loops.
VOTES-- MORE SERIOUSLY....CODING CAN BE ABOUT AESTHETICS. YES, JUST BECAUSE. CODE CAN LOOK GOOD AND THAT IS A VALUE. BUT ALSO, AESTHETICS CAN HAVE A NON-MEANINGLESS AFFECT ON COMPREHENSION, READABILITY, CODING-PLEASURE AND PRODUCTIVITY. SO MONEY, BASICALLY. PERSONALLY, I LOVE THE ++ AND -- AESTHETIC. IT'S JUST A COOL GLYPH/DIGRAM/IDIOM. BRING BACK THE QUIRKINESS ( OKAY, NOT TO THE PERL-LEVEL ) BUT BRING IT BACK!
But retaining x += 1? That one has always annoyed me. Why does '+' (and friends) get this special form, but not my functions? Just because they're built-in.
They are useful; no argument there. Largely because 'x' can be a complex reference, and you don't have to type it twice (and the compiler doesn't have to figure out that its the same expression twice). E.g. x=x+1 is short but (rec)FnRec(iRec) = (rec)FnRec(iRec) + 1; is not short. And the compiler gets some great hints when the '+=' form is used (don't calculate the reference twice).
I just want that for my stuff too! E.g. I may have a transformation method Xform(Foo&, Bar) that returns another Foo&. I want to say foo = Xform(foo, bar); but with 'foo' replaced by a complex reference. I have to say FnFooRef(iFoo, "primary", red) = Xform(FnFooRef(iFoo, "primary", red), bar)
instead of FnFooRef(iFoo, "primary", red) Xform= bar;
I want my own 'operators' with the 'op=' syntax supported.
Probably its not terribly useful any more; languages support immutable data and tuples and so much that don't work this way at all.
Earlier quoted context omitted.
Because non-advanced users will incorrectly abuse them. That's why ARC doesn't let you call retain and release manually, even though there's no technical reason it couldn't.
So? Advanced developers abuse languages all the time. This isn't a valid argument.
I mean, its predecessor allowed you to mutate your class hierarchy at runtime, and this was a thing that people commonly did!
"You can't do that" is a powerful tool for making code safer.
Earlier quoted context omitted.
> Because non-advanced users will incorrectly abuse them. I don't see how this is a valid reason to remove the operators completely. Beginners will get it wrong sometimes, so we should remove it? Beginning users are likely to make all kinds of errors, so the implication would be maybe we should remove the entire language...? Not to mention, pre-decrement and post-decrement are not complicated concepts. There are many…
Well, the same argument can be made for pointers, which are clearly harmful to a safe language. Swift does include them, but puts a screaming "Unsafe" in front of their type names so that it's clear that unless you really know what you're doing, you're probably doing something wrong. There's no way to do that with a ++ operator, so it's being removed.
> Their expressive advantage is minimal - x++ is not much shorter than x += 1. And there is no ++ equivalent of x += 2.
Yes. Anointing "+ 1" as a thing that needs special syntax is weird .
> Anointing "+ 1" as a thing that needs special syntax is weird.
1 is special.
Earlier quoted context omitted.
Well, the same argument can be made for pointers, which are clearly harmful to a safe language. Swift does include them, but puts a screaming "Unsafe" in front of their type names so that it's clear that unless you really know what you're doing, you're probably doing something wrong. There's no way to do that with a ++ operator, so it's being removed.
Do really think the complexity of pre/post-in/decrement is on the same level as pointers?