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