Bob Arning <arning at charm.net> wrote:
	My disquiet with the implementation of #ifTrue:.. is that the
	brackets are required even when it is of no concern to me
	whether the code gets evaluated unnecessarily or not.  Or even
	when I want both to be evaluated.  Consider:
	
		a := a + 1.
		b := b + 1.
		^cond ifTrue: [a] ifFalse: [b]
	
	[which] could be written as
	
		^cond ifTrue: (a _ a + 1) ifFalse: (b _ b + 1)
	
	if the compiler were a little friendlier to harder-to-optimize
	code and Object understood #value.

Yike!  Say no more; this example damns the proposal more than anything I
could have thought of.

Is it really necessary for me to point out that adding
    False>>ifSo: x ifNot: y ^y
    False>>ifNot: y ifSo: x ^y
    True >>ifSo: x ifNot: y ^x
    True >>ifNot: y ifSo: x ^x
takes only a few seconds, and lets anyone write

    ^cond ifSo: (a _ a+1) ifNot: (b _ b+1)

who really wants to, *without* changing the meaning of *any* existing
message, and *without* blocking future definitions of #value ?

	We seem to be hung up on special treatment for
	#ifTrue:ifFalse:  and I don't quite understand why.
	
No, the point is that #ifTrue:ifFalse *doesn't* have special
treatment, and that is *why* the block brackets are required.

Offhand, I could count the number of times I've wanted an
if-that-evaluates-all-arguments in any of the >150 programming
languages I've used on the fingers of one eyebrow.