8

In the past, I've attempted to perform variable assignment and conditional evaluation within the parentheses of the if statement and at the time I wrote that code, the Apex compiler returned with an error message stating that it expected a condition evaluation and received an assignment operator (or something to that effect).

Because of this compilation error message at that time, I was immediately taught that in Apex this cannot be done, until today. I am now able to write code which does not present this error message, compiles fine and runs, evaluating to true and entering the following block of logic (exactly as the written code logic says it should).

// bug because the condition should have been written with a double equals operator
if (myRecord.Billable__c = true) {
    myRecord.BillableCalculationReason__c = '';
}

As seen below, it's not just for boolean type assignments either:

string testString = 'abc123';
system.debug('Before: ' + testString);

if ('def456' == (testString = 'def456')) {
    system.debug('Inside the block.');
}

system.debug('After: ' + testString);

12:49:33.037 (37383000)|USER_DEBUG|[2]|DEBUG|Before: abc123
12:49:33.037 (37429000)|USER_DEBUG|[5]|DEBUG|Inside the block.
12:49:33.037 (37455000)|USER_DEBUG|[8]|DEBUG|After: def456

Did the Apex compiler change recently to allow both assignment and evaluation in this manner or is this an edge case that the compiler somehow doesn't catch? (Tested in API v.28 & v.29)

  • 2
    For bonus points, one should note that the assignments work as they do in C/C++ now (they do assign correctly, instead of a compiler error or some bug), and have been retrofitted into all prior versions (tried all way down to v10.0, and saved successfully). I scoured the last three release notes (the coming Spring '14, and the prior Winter '13 and Summer '13 notes), with no mention of this change appearing in any document (that I could find). – sfdcfox Jan 27 '14 at 22:20
  • 1
    I take it to mean that LValues are now RValues as well, which makes sense in the classic sense because it was perfectly legal to write Account a, b, c; c = new Account(); a = b = c; prior to this change in the compiler. – sfdcfox Jan 27 '14 at 22:24
  • 2
    I helped Mark discover this phenomenon this morning. Thanks Mr. Fox for plugging it in all the way back to 10. What I'm more curious about is whether my memory was off and I imagined not being able to compile assignment within a condition, or if something truly did change. I could have sworn that compile error saved me from bugs several times in the past... This not something I would normally imagine. Thanks! – user3202 Jan 27 '14 at 23:16
  • @sfdcfox do you know if this is a change? Do you remember the complier error which I'm referring to in this scenario or am I possibly remembering it incorrectly? – Mark Pond Jan 27 '14 at 23:16
  • Yoda conditions never killed anyone... at least it only compiles with Boolean expressions! – bigassforce Jan 27 '14 at 23:25
3

I created a class that did this kind of assignment in a class and set the API version back to 10.0 - that still saved OK so either

  • The compiler has changed and the change is global for all API versions (seems unlikely that Salesforce would do this)
  • You're potentially remembering errors where you tried a bad assignment, i.e. if(true = bool)
  • Something else?
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.