Hi Nikolai,

On 31/01/12 18:57, Nikolai Weibull wrote:
> On Tue, Jan 31, 2012 at 08:57, Garthy D
> <garthy_lmkltybr / entropicsoftware.com>  wrote:
>
>> On 31/01/12 17:16, Gavin Sinclair wrote:
>
>>> # The following causes a SyntaxError: multiple assignment in conditional.
>>> if (a, b = foo)
>
>> I can understand why the language rejects that construct (I've never tried
>> it myself- an interesting find!). The method itself would be returning an
>> array (correct?), and an array would always be treated as true in the
>> expression, regardless of the results. Thus, it is likely to be some sort of
>> error (why put an always-statically-true expression in a conditional?), and
>> hence knocks it back with an error.
>
> if true
>    puts 'well that°«s a relief'
> end

Haha, I *knew* someone would call me out on that one if I wasn't more 
specific. What I didn't expect was how little time it'd take. ;)

To clarify: If "if (a, b = foo)" would always evaluate to true, it might 
cause confusion for someone expecting it to base the evaluation on one 
of the assigned variables; whereas the intent for "if true" is  pretty 
clear; it's an expression with less than two assignments.

Still, it's not necessarily a strong argument or one I'd get behind. I'm 
just saying that I understand why it might have turned out that way. 
Maybe the potential for confusion led to that particular design decision?

>> I'm wondering as to the best behaviour if it were actually handled directly
>> by the language (which I'm not specifically suggesting). True if any of the
>> multiple assignments evaluate to true? Or just the first? Or last? Certainly
>> not always-true. I can't say I'd know a sensible default. :/
>
> [a, b, °ń].any?
>

Indeed, that's another possibility, although I'll point out that it's 
inconsistent with an empty array normally being treated as true in an 
ordinary expression. But hey, we are working with an odd case here, so 
why not? :)

Garth