Klaus D. Witzel wrote:
> Ah. And I was believing the description in True>>#ifTrue:
> -------
> ifTrue: alternativeBlock
>     "Answer the value of alternativeBlock. Execution does not actually
>     reach here because the expression is compiled in-line."
> 
>     ^alternativeBlock value
> -------
> 
> So the bug is in the documentation? This is not an easy one: who would 
> doubt the implementation of such an essential behavior?

I don't see a bug in either the implementation nor the documentation of 
ifTrue:/ifFalse:. You need to look at False>>ifTrue: if you want to 
understand the described behavior of ifEmpty:

False>>ifTrue: alternativeBlock
	"Since the condition is false, answer the value of the false alternative,
	which is nil. Execution does not actually reach here because the
	expression is compiled in-line."

	^nil

And now it gets perfectly clear that if you want your result in ifEmpty: 
you need to change it to something like here:

Collection>>ifEmpty: aBlock
         "Evaluate the block if I'm empty"

         ^ self isEmpty ifTrue: aBlock ifFalse:[self]
                                       ^^^^^^^^^^^^^^

(note that even if False>>ifTrue: were implemented differently it 
couldn't possibly return anything that was involved in the computation 
of that boolean value so regardless of whatever you're trying to do 
[True|False]>>ifTrue: is the wrong place to achieve it - at best it 
would result in ifEmpty: returning false instead of nil ;-)

Cheers,
   - Andreas