What is that a F*...Calm down man, or take your little pills, It's just a question
Just try... You are a grown up boy.
What is that a F*...
Just try... You are a grown up boy.
Since it's declared in the System unit it won't interfere with the
IfThen()s that are declared in the Math unit or other units, so they'll
continue to work as before to avoid any surprises.
uses math;
ifthen(true, a,b )
Good thing I just installed fpc trunk.
BUTCode: [Select]uses math;
ifthen(true, a,b )
evaluates both branches
It is quite unfortunately named, if it gets overriden by the math functions
function IfThen(Condition: Boolean; ThenExpr, ElseExpr: type): type;
...
An important point to note is that in general the result type is
determined by the ThenExpr (there are a few usability exceptions
regarding strings and chars).
Oh God… not again! We already have had hundreds of email about this on the list. :DIndeed. This is how a technical non-problem turns into a political dispute.
x:=if a then b else c;
would be possible. It might look nice, but ... x:=if true then 5 else 3 + 4;
should it be resolved as: x:=(if true then 5 else 3) + 4;
or x:=(if true then 5 else (3 + 4));
If using intrinsic, is really not a problem, since function call (which it looks like) takes the higher precedence: x:=IfThen(true, 5, 3)+4;
So defining the right precedence is critical to usability of an operator, since it might be a source for potential bugs.But here comes the problem:
The intrinsic looks like a function, but acts differently. In case of a function all arguments are evaluated prior to the function call. That might cause confusion, even though there're already intrinsic that're acting in a similar manner, i.e. assert().
Logically, it's better to have as less exceptions as possible, that's why it is desirable not to add another exception into RTL.
So, in the thread another proposal came up - let's have if..then as an expression. That would make if..then an operator. With implementing this, a code likeCode: [Select]x:=if a then b else c;would be possible. It might look nice, but ...
whenever a new operator is introduced, it must have a defined precedence. For example, what the value of x would be:
Hello, i've just read this:
http://lists.freepascal.org/pipermail/fpc-pascal/2016-January/046375.html
which basically announces that something like C ternary expressions is implemented in FPC trunk.
Will it work with += and -=, when C-like operators are activated ?
What makes it all hard (over 200 emails of the mailing list), is that the patch has already been provided, it's very easy to accept it technically.Yup. There are too much such constructs in Free Pascal already. That is why I started the MSElang initiative.
The optimal solution might be - not to do anything. Put the patch on hold, until the language is ready for it or until Delphi implements it also. (I wonder if Delphi developers had the same problem and decided not to add it to the language)
The optimal solution might be - not to do anything.
Put the patch on hold, until the language is ready for it
or until Delphi implements it also. (I wonder if Delphi developers had the same problem and decided not to add it to the language)
IIF(Cond, Result1, Result2) is a shortcut for “CASE WHEN Cond THEN Result1 ELSE Result2 END”. You can also compare IIF to the ternary “? :” operator in C-like languages.So, it behaves just as our new intrinsic.
Recently generic were implemented for functions. That pretty much opened the door to implementing the IfThen() via regular language feature rather than a compiler intrinsic. Though there were an issue Silvio ran into. (Note: reporting the issue actually inspired compiler - intrinsic solution).Put the patch on hold, until the language is ready for it
until the language is ready - I do not understand when and how do you think the language can become more ready for this feature?
I hope that we will see it in FPC as soon as possible, that is in the next release.Does it actually prevents you from completing your project? :)
Recently generic were implemented for functions. That pretty much opened the door to implementing the IfThen() via regular language feature rather than a compiler intrinsic. Though there were an issue Silvio ran into. (Note: reporting the issue actually inspired compiler - intrinsic solution).
Another potentially possible approach is to have an inline function modifier to be evaluated on the first use, rather than prior to the call (as it is done right now). It would make inline functions to act similar to achieve the same functionality. However, implementing such argument modifier could be really tricky.
...who knows what other language features could be introduced, that would help to implement IfThen()
I hope that we will see it in FPC as soon as possible, that is in the next release.Does it actually prevents you from completing your project? :)
I do not understand the excitement. I use the following easy function, and I think that is meant by this discussionYou do understand that the following code
b := true;
a := IFFork (b, 5 + 5, 3-2);
does a useless job of calculating 3-2, since only 5+5 should be evaluated? b := true;
if b then
a := 5+5
else
a:= 3-2;
doesn't have such deficiency.
Yup. There are too much such constructs in Free Pascal already. That is why I started the MSElang initiative.
Sorry, I cant see a big difference
x := ifthen(obj <> nil, obj.foobar, '');
x := if obj <> nil then obj.foobar else '';
Sorry, I cant see a big difference
{$mode objfpc}
{$assertions on}
uses SysUtils;
var
a,b : integer;
begin
a:=4;
b:=0;
assert(b =0, 'the result if of division is '+IntToStr(a div b));
writeln('b is zero!');
end.
Does it fail?{$mode objfpc}
{$assertions on}
uses SysUtils;
procedure myassert(cond : boolean; const msg: string); inline;
begin
if not cond then begin
writeln(msg);
halt;
end;
end;
var
a,b : integer;
begin
a:=4;
b:=0;
myassert(b =0, 'the result if of division is '+IntToStr(a div b));
writeln('b is zero!');
end.
Does it fail? if yes, what's the error message?
Code: [Select]
x := ifthen(obj <> nil, obj.foobar, '');
You cannot do that with the old version
http://lists.freepascal.org/fpc-pascal/2016-February/046616.htmlFor the best, imho!