ID:1351233
 
Not a bug
BYOND Version:N/A (Website Bug)
Operating System:Windows 8 Pro 64-bit
Web Browser:Internet Explorer 10.0
Applies to:DM Language
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:The -- operator's DM Reference is slightly wrong...

Numbered Steps to Reproduce Problem:
Go to the DM Reference here...

http://www.byond.com/docs/ref/info.html#/operator/--

Code Snippet (if applicable) to Reproduce Problem:
var/A = 0
world << "A-- = [A--]" // outputs "A = 0"
world << "--A = [--A]" // outputs "A = -2"


Expected Results:
It to show the real output completely instead of telling the value of A.

Actual Results:
The DM Reference shows most of the output but not the exact output.

Does the problem occur:
Every time? Or how often?Every Time
In other games?Not Applicable
In other user accounts?Not Applicable
On other computers?Not Applicable

When does the problem NOT occur?Always

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Not Applicable

Workarounds:Not Applicable



My simple proposal here is a few things...first off the output would be exactly as follows...

var/A = 0
world << "A-- = [A--]" // outputs "A-- = 0"
world << "--A = [--A]" // outputs "--A = -2"


But it's somewhat mis-leading to people just glancing at it, because the double use of the same operator.

After line 2, it would output 0, yes, but A would now be negative 1, and for line 3 negative 1 minus one more is indeed negative 2, but if someone just glances for an example of each as if their separate, which they for all general purposes are, they may wonder why the 3rd line says negative 2 if A is 0, even though line 2 made that not so.

Since as all of us now, but not beginners which will be using the reference know, since the 2nd --A has the []'s around it, it makes it evaluate it and do something where-as ones outside of it don't...I have been asked a few times now why it's negative 2 or why after line 2, A is only negative 1, as the output not showing the exact output makes it more mis-leading to people looking thinking it's evaluating both of them, and leaving the A to display after the subtraction...even though that's not accurate.

No big deal, I think the reference should split the examples in the operator's reference & use the exact output so it doesn't fool them into thinking it's evaluating & subtracting from both of the --A's even though only one is the []'s
In addition to this...the ++ operator seems to show the exact output already, even though -- doesn't but still puts together both usages of it, to make someone just glancing potentially confused since they are 2 separate uses, they may wonder how it really works, since they aren't taking into account the 2nd line increasing the value before you even get to line 3...I think these examples should be separated in the ++ operator as well as the -- operator.

Link to the other operator: http://www.byond.com/docs/ref/info.html#/operator/++
This isn't very clear to me. What exactly are you suggesting? As far as I can tell the reference is correct.
Basically, he's suggesting that the reference is confusing.

Postdecrement and predecrement are tough concepts, he thinks, and leads to much confusion, and as such, should be explained in a better way, possibly having two separate entries. (which I think is a mistake)
Nadrew resolved issue (Not a bug)
var/A = 0
world << "A-- = [A--]" // outputs "A-- = 0"
world << "--A = [--A]" // outputs "--A = -2"

This suggests that --A will decrease A by two while A-- will do nothing. A better illustration would be to reset A between the two outputs and add an [A] to the end of them, like so.

var/A = 0
world << "A-- == [A--], A == [A]" // outputs "A-- == 0, A == -1"
A = 0
world << "--A == [--A], A == [A]" // outputs "--A == -1, A == -1"
In response to MisterPerson
MisterPerson wrote:
var/A = 0
> world << "A-- = [A--]" // outputs "A-- = 0"
> world << "--A = [--A]" // outputs "--A = -2"
>

This suggests that --A will decrease A by two while A-- will do nothing. A better illustration would be to reset A between the two outputs and add an [A] to the end of them, like so.

var/A = 0
> world << "A-- == [A--], A == [A]" // outputs "A-- == 0, A == -1"
> A = 0
> world << "--A == [--A], A == [A]" // outputs "--A == -1, A == -1"
>

That's a clearer explanation, and I can see what you're getting at. One minor suggestion: I'd recommend the second [A] be a different output. I'm reasonably certain there's a sequence point in between two embedded expressions, but it's a bit like operator precedence IMO - even if you think you know how it goes you probably shouldn't rely on it.
In response to MisterPerson
I was thinking that the example was a bit misleading too, but I think that could be fixed simply by adding a clause to the 1st comment line that explains that the value of A has changed:

var/A = 0
world << "A-- = [A--]" // outputs "A-- = 0" (though A will be changed post-output to a value of -1)
world << "--A = [--A]" // outputs "--A = -2" (this operator changes the value of A pre-output)
Currently the reference is not correct in the sense that the outputs are slightly wrong, doesn't change the meaning, it's a small inconsistency though.

Incorrect:
var/A = 0
world << "A-- = [A--]" // outputs "A = 0"
world << "--A = [--A]" // outputs "A = -2"


Though I feel that breaking the example up would make sense.

Correct:
var/A = 0
world << "A-- = [A--]" // outputs "A-- = 0"
world << "--A = [--A]" // outputs "--A = -2"


var/A = 0
world << "A-- = [A--]" // outputs "A-- = 0"
world << "A = [A]" //outputs "A = -1"


var/A = 0
world << "--A = [--A]" // outputs "--A = -1"
world << "A = [A]" //outputs "A = -1"