On 02/02/16 16:28, Lukasz Sokol wrote:
> (bikeshedding mode=on)
> 
> On 02/02/16 11:24, Marcos Douglas wrote:
>> On Tue, Feb 2, 2016 at 7:49 AM, Michael Van Canneyt
>> <mich...@freepascal.org> wrote:
>>> It is not a statement, it is an expression.
>>>
>>> I prefer
>>>   x := iif Obj = nil then 0 else Obj.Value;
>>> over
>>>   x := if Obj = nil then 0 else Obj.Value;
>>>
>>> Because it clearly differentiates between if (a statement) and iif (an
>>> expression)
>>>
>>> So the iif in either functional or expression form has my vote.
>>
>> +1
>>
>> And why not use 'inline'?
>>
>>   x := inline if Obj = nil then 0 else Obj.Value;
> 
> and what if the definition was
> 
> x := (if condition then value1 else value2);
> 
> that is REQUIRING round parentheses around this construct - 
> no need for 'inline' keyword and compatible with code beautifiers (of sorts) 
> and thanks to parentheses, showing exactly it's a statement, returning a 
> value like an expression...
> 

To add to that...

i have seen (and used at start and still at times) coding the explicit order of 
calculations 
(like evaluating numerical expressions..) by inserting parentheses and not 
assuming the right order 
will be deduced by the compiler from 'just' writing the formula down in 
flattened form. 

Newbie stuff, yes, but at least the order of parentheses-driven evaluation 
seems to be guaranteed and is 
relatively timeless... and language-agnostic, even the scripting slangs honour 
that.

I believe this kind of explanation of-sorts plays with what may be going on in 
this construct ?

>>
>> It's not necessary add one more keyword like "iif", I think.
>>
>> Best regards,
>> Marcos Douglas
> 
> el es
> 
el es

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to