The problem is that in this case: 10 ifTrue: [ #falseResult. ]. #unexpectedResult. #falseResult => is used for effect. Opal removes it. 10 ifTrue: [ #falseResult. ] => is used for effect. Opal removes it. The bytecode ends up being: *29 <20> pushConstant: 10* *30 <87> pop* *31 <78> pushConstant: #**unexpectedResult* So the DNU does not happen. Such bytecode optimisation should be postponed to runtime (Cogit, Sista) and not be performed by Opal. We did not know that when we wrote Opal. We may want to fix this. On Fri, Mar 3, 2017 at 6:03 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hi.

try these expressions in playground:

10 ifTrue: [ #falseResult ]. "=>DNU #ifFalse".

10 ifTrue: [ #falseResult. ]. #unexpectedResult. "=> #unexpectedResult"

10 ifTrue: [ #falseResult asString]. #unexpectedResult. "=> DNU #ifTrue:"

Same happen with ifFalse: and ifTrue:ifFalse couples.

If you look at bytecode you will not see any jumps in not failing cases. Probably such code is redundant because it not produce any behaviour. It start to work properly as soon as there is any assignment or message send around. But it is really strange from first look. Also it means that special boolean objects with own ifTrue:ifFalse implementation will not receive messages in such cases.

I am not sure if it is a bug