About the endless discussion on adding increment/decrement operators in Xojo, seems the trend is in the opposite direction:
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md
Ha! 
that’s because += is available
To be fair with Apple, now that probably a significant number of people have probably used ++ I am not sure it is a good idea to take it from under their feet.
Deprecating means not taking it from under the feet.
You get warnings for some time, before you start getting compilation errors.
I can agree with part of that discussion… although in parts it seems confusing as to what form he is describing
- y=x++
- y = --x
- y = ++x
*y = x–
Those I can see to be confusing seeing as they alter both X and Y, and I’d have no problem removing those
- x++
*x–
I see no reason to remove those, are they less intuitive than these?
- x+=1
- x-=1
Actually I think so, but there are many ObjC programmers moving to Swift, and those that are going there from a non “C” based language still have the option of not using those and using
- x=x+1
- y=y+1
[code] Sub Dec(Extends byref i as integer)
i = i - 1
End Sub
Sub Inc(extends byref i as integer)
i = i + 1
End Sub[/code]Unless the restricted it to JUST a postfix inc or dec on a line with NO other assignments operations etc" a person still write
y = x++
and you still have both x and y being altered in one line of code
suppose x = 3
and you execute y = x++
I’d bet a lot of people get what values are in x and y wrong because this executes more like
y = x
x = x + 1
keeping it “because it like that in C” means “its obtuse and maps to a machine that no one has used in 30 years”
Norman. that was my point… versions of this where TWO variables are involved are confusing…
So… I could support removing “y=X++” but keeping “X++” where ++ only affects X and there is NO assignment
I’d hate writing the grammar for it 
Can’t you make the Lexical “cheat”?
Replace "$variable$++" with "$variable$=$variable+1"I’ll mention again, if anyone wants it, that I have a Keyboard Maestro macro that lets you type:
variable??and it instantly replaces that with
variable = variable + 1("?" is option-+ on my Mac keyboard, and I introduced option since I had cases when the macro would fire unintentionally.)
The grammar would have to allow it nearly everywhere and then semantic analysis would have to reject certain uses
You usually don’t want the grammars to have to have contextual knowledge
It makes stuff very messy
[quote=233697:@Massimo Valle]About the endless discussion on adding increment/decrement operators in Xojo, seems the trend is in the opposite direction:
[/quote]
Nice forum topic @Massimo Valle! Honesltly I think this is again lately Apple Marketing treating C as an evil language. IMO it’s marketing bullshit.
i++; It’s less cryptic than some other exotic languages.
1) Keep both x++ and ++x in the language, even though they do the same thing.
2) Drop one of x++ or ++x. C++ programmers generally prefer the prefix forms, but everyone else generally prefers the postfix forms. Dropping either one would be a significant deviation from C.[code]As a quick refresher, there are four operators in this family:
let a = ++x // pre-increment - returns input value after mutation
let b = x++ // post-increment - returns copy of input value before mutation
let c = --x // pre-decrement - returns input value after mutation
let d = x-- // post-decrement - returns copy of input value before mutation
[/code]
I really love the debate about this that will never, ever, dye. I think it’s better to avoid pre-drecement (–foo) and keep bar+++ as something really understandable to any that approach computing. It’s shorter and widely understandable.
Thanks for so interesting tread.
Amando
1) Keep both x++ and ++x in the language, even though [b]they do the same thing[/b].Argh… this is utterly false! :S
on a single statement basis
x++ ;
and
++x ;
are equivalent
Its when you use them in loops, assignments or other places where they are legal that the weird effects come into play
y = ++x
is not the same as
y = x++
nor do these two loops do the same thing
for ( int i = 1; i < 100; ++i )
for ( int i = 1; i < 100; i++ )
more complex examples are certainly available
[quote=233845:@Norman Palardy]Its when you use them in loops, assignments or other places where they are legal that the weird effects come into play
[/quote]
LOL! Gimme a beer for each…
Yeah, it’s the problem with this. Still a foo++; it’s understandable. Don’t you think so?
as a single statement on a line by itself its no better or worse than i = i + 1 or i += 1
I kind of prefer the last one since ++ is a VERY narrow use case
And since in Xojo for loops you don’t have to specify an increment and its implicitly 1 that narrows its usefulness further (unlike in C where you do have to write the increment)
+= would let you do += 1 or 2 or 3 or whatever so I think it has potentially wider use and is at least as easy to read
[quote=233847:@Norman Palardy]as a single statement on a line by itself its no better or worse than i = i + 1 or i += 1
[/quote]
I don’t see the C cleverness use of assigning --foo besides a loop. That’s why I think this is pure marketing.
bar++;
It’s readable… really. Bar = Bar + 1.
Shortcuts helps 
Heh
History more than anything
Unix and C were written on PDP’s and a lot of the C primitives mapped into PDP instructions really simply
And there are some other … useful ? … effects that pre & post operators had
But those concerns were nearly 50 years ago and Swifth has adopted clarity safety etc as its mantra
++ as pre & post are not exactly “clear” in a lot of use cases
And they still exist in C and C++ and are fully supported - and still causing new folks havoc