functional IF lazarus / 62-General ---------------------------------------------------------------------- jamie · 2025-06-01 18:09 Quote from: PascalDragon on November 30, 2021, 11:23:16 pmQuote from: marcov on November 29, 2021, 12:50:19 pmQuote from: MarkMLl on November 29, 2021, 11:47:34 amHowever as a counterexample I'd like to highlight the ALGOL-style conditional expression that Wirth unaccountably omitted from Pascal: Code: [Select]  a := if b then c else d; since this can't easily be emulated using a function and is such a common idiom in mainstream ALGOL derivatives- by which I of course mean C etc.- that its absence is embarrassing. Hasn't there has been talk about this, ifthen() becoming an intrinsic and only evaluating the sides as necessary.   (because objective pascal needed it???) I don't know if it happened in the end. Maybe Pascaldragon knows. I had added it back in January 2016 (see announcement mail of which the thread continued into February). After some heated discussions both on the public mailing list as well as the core one I removed it again in February. The addition of the intrinsic is still part of the version history and I think somewhere I still have a patch for the if … then … else - expression (alternatively it would be easily derivable from the provided commit for the IfThen intrinsic). You keep threatening us with that addition!, I am still waiting!  Show me the code so I can convert these C programs over better since they are loaded with things like that and need to really do some heavy workarounds to avoid unwanted function calls.  Also, This  If then Else etc should work nested wise too!   I am not asking for must, just show me the CODE!  Jamie ---------------------------------------------------------------------- Thaddy · 2025-06-02 11:04 Regarding the ifthen intrinsic that did not last long, there is now something similar in main because of implicit function specialization. It is also nestable. [slight mod done later] Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$mode delphi}{$h+}{$modeswitch implicitfunctionspecialization}{$modeswitch functionreferences}uses   sysutils; type  TMyref = reference to procedure;    procedure test1;  begin    writeln('test1');  end;   procedure test2;  begin    writeln('test2');  end; var   a:integer = 100;b:integer = 50;  c:string = 'test';d:string = 'test';  e:double = 1.0;f:double = 1.0;  g,h:TMyref;begin  g := test1;  h := test2;  ifthen(true,g,h)();  ifthen(false,g,h)();  writeln(ifthen(b < a,b,a));                  writeln(ifthen(c = d,'equal','not equal'));  c := extract(d);  writeln(ifthen(c = d,'equal','not equal'));  writeln(ifthen(e = f,e,f):2:2);end. ---------------------------------------------------------------------- jamie · 2025-06-02 12:55 @thaddy   Not the same and never will be unti the operation is intrinsic to avoid executing unwanted code. ---------------------------------------------------------------------- Thaddy · 2025-06-02 20:21 I know, but it is close and has very little speed penalty due to the nature of generics. ---------------------------------------------------------------------- Warfley · 2025-06-05 20:41 Was bored and wanted to see how long it takes to build something like that: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var  s: string;begin  s := if 0 < 1 then 'Foo' else 'Bar';  WriteLn(s);end. It's roughly 30 lines of code and took 15 minutes to create the attached patch for fpc main ---------------------------------------------------------------------- jamie · 2025-06-07 10:10 Quote from: Warfley on June 05, 2025, 10:41:05 pmWas bored and wanted to see how long it takes to build something like that: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var  s: string;begin  s := if 0 < 1 then 'Foo' else 'Bar';  WriteLn(s);end. It's roughly 30 lines of code and took 15 minutes to create the attached patch for fpc main Does it work for a parameter inside a function parms list ? Can the foo or bar be replaced with another construct of this to return the value, nested? Jamie ---------------------------------------------------------------------- Warfley · 2025-06-07 10:37 It's a completely normal expression you can use anywhere. The type of the expression is the type of the result of the if branch. That said, I have not looked to much into where in the operator precedence it falls, so best to use brackets, but the following should work just fine: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i s := if cond1 then 'Foo' else     if cond2 then 'Bar' else     'Baz'; When you use incompatible types it will show on the else branch: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i s := if 0<1 then 'Foo'     else 32; // Error expected StringConstant got ShortInt ---------------------------------------------------------------------- Fibonacci · 2025-06-07 10:41 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i uses SysUtils;var  s: string;begin  s := 'test';  writeln(if (if s = 'test' then 0 else 1) < 1 then if GetTickCount <> 123 then FormatDateTime('hh.nn.ss', Now+if true then 1 else 0) else 'Foo' else 'Bar'); Awesome, merge it ---------------------------------------------------------------------- jamie · 2025-06-07 10:55 Yes, please meege and relase fpc with that in it. Ill put my delphi away. ---------------------------------------------------------------------- MarkMLl · 2025-06-07 11:34 Quote from: jamie on June 07, 2025, 12:55:33 pmYes, please meege and relase fpc with that in it. Ill put my delphi away. I certainly feel it would be worth getting that into the feature- request list, since it was a feature missing from Wirth's original language rather than just-another-recently-tacked-on-frill. Even if we expect the core team to continue to reject such things. MarkMLl ---------------------------------------------------------------------- Warfley · 2025-06-07 12:14 Creating the patch was the easy part, if I wanted to make a merge request it would take at least double the time to make test cases for it lol But aside from that, I'm not happy with it, because it's a bit weird to have this for if but not for other statements. What about case? Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i s := case state of  0: 'Foo';  1: 'Bar';  2: 'Baz';  else 'FooBar';end;Or what about try-except: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i s := try functionThatCanFail() except 'Error';And when try-except is in there, what about raise: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i s := try functionThatCanFail() except on E: ESomeException do 'Bar' except raise;Also useful for incomplete cases: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i s := case State of1: 'Foo';2: 'Bar';else raise EUnknownState.Create(state);end; ---------------------------------------------------------------------- jamie · 2025-06-07 13:36 Well, either way, as long as it returns as a result. If long as we can do that as an expression that works well too and may look cleaner. Jamie ---------------------------------------------------------------------- 440bx · 2025-06-07 14:34 the posts about implementing the if else as an rvalue should probably be split into another thread as that has nothing to do with break out early of a case statement. ---------------------------------------------------------------------- MarkMLl · 2025-06-07 18:39 Quote from: Warfley on June 07, 2025, 02:14:11 pmCreating the patch was the easy part, if I wanted to make a merge request it would take at least double the time to make test cases for it lol I'm tempted to ask "what can we do to help?" but since the patch took you 15 minutes it would probably take more than 30 for you to explain the additional detail :-) QuoteBut aside from that, I'm not happy with it, because it's a bit weird to have this for if but not for other statements. What about case? That's a possibility I've raised in the past, but I'd make two comments. First, the if-then-else expression was in ALGOL-60 and, via C, is in most of its derivatives. There is no general acceptance of an if-case- else expression, although I suspect that aspects of it overlap with some of the tuple handling that I believe Sverah has looked at. Second, Pascal's case statement does not have a mandatory else/otherwise part, but a case expression would have to have one. Third, if then else associates a boolean true (variously described as either evaluating to 1 or to non-zero) with . However, one would reasonably expect a case-else expression to evaluate from zero upwards, which immediately gets conceptually messy. (Detail: I've tackled this in the scripting stuff that runs my business, and ended up defining distinct expressions to handle the two variants). OK, that's three. Sorry. If I had to rate them, I'd say that they're already in order of importance. MarkMLl ---------------------------------------------------------------------- 440bx · 2025-06-07 20:15 All of this is off-topic. Please get back on topic, which is, breaking out early of a case statement. ---------------------------------------------------------------------- Warfley · 2025-06-07 22:34 Quote from: MarkMLl on June 07, 2025, 08:39:39 pmI'm tempted to ask "what can we do to help?" but since the patch took you 15 minutes it would probably take more than 30 for you to explain the additional detail :-) If you want to, just write tests. Positive tests like: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var  s: String;begin  s := if 0 < 1 then 'Foo' else       if 1 < 2 then 'Bar' else       'Baz';  WriteLn(s);  if (s<>'Foo') then    Halt(1);end. Or negative tests like: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {%FAIL}var  s: String;begin  s := if 0 < 1 then 'Foo' else 32;  Halt(1);end. But the reason I just put a little patch here instead of creating a merge request is simply because I don't think this would be accepted. It's a very small update which, if you look a the intrinsic already was commited, but not accepted. And while I personally think doing it as an intrinsic is a bad idea (if it looks like a function it should behave like a function, while the explicit purpose of this is to not behave like a function), I don't think things are different for this. Also I still have a long list of merge requests from last year I did not have the time to follow up on, so I don't want to open another. That said, I might work a bit more on this patch just for funsies and see where it is going Quote from: MarkMLl on June 07, 2025, 08:39:39 pmFirst, the if-then- else expression was in ALGOL-60 and, via C, is in most of its derivatives. There is no general acceptance of an if-case-else expression, although I suspect that aspects of it overlap with some of the tuple handling that I believe Sverah has looked at. Second, Pascal's case statement does not have a mandatory else/otherwise part, but a case expression would have to have one. Third, if then else associates a boolean true (variously described as either evaluating to 1 or to non-zero) with . However, one would reasonably expect a case-else expression to evaluate from zero upwards, which immediately gets conceptually messy. (Detail: I've tackled this in the scripting stuff that runs my business, and ended up defining distinct expressions to handle the two variants). The thing with case is quite simply it's first very efficient, but more so allows to easily compare multiple values like: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i case State of2, 5, 8, 10..15: 'Foo'else 'Bar'Would be in if-then-else: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i if (state=2) or (state=5) or (state=8) or ((state>=10) and (state<=15)) then 'Foo' else 'Bar'And yeah, case needs to either be exhaustive, or have an else statement, or another solution would be to raise an error (maybe even re-use range errors) when the value falls outside of the covered cases. ---------------------------------------------------------------------- jamie · 2025-06-07 22:46 Those that don't want it don't need to use it, correct? I mean, its not going to change the rest of the compiler's functionality. I personally would like to see that intrinsic of at least the IF THen ,,,,,, As for the CASE, that I can see would get a little messy however, I guess you could also include that too, and like I said, those that don't like it don't need to use it, period!   I use the IFThen a lot but it really suffers when calling functions for the results. it should work like a real iF then else etc.  Of course, Delphi does not have this, yet but that isn't an excuse. Give them time and they will have it too. Jamie ---------------------------------------------------------------------- Thaddy · 2025-06-08 05:57 Quote from: MarkMLl on June 07, 2025, 08:39:39 pmSecond, Pascal's case statement does not have a mandatory else/otherwise part, but a case expression would have to have one.If you accept that ISO 10206 is an extension to ISO 7185 then, according to the standard, otherwise is mandatory if not all cases are covered. The  compiler throws a warning in all dialects but ExtPas where it should throw an error. ---------------------------------------------------------------------- MarkMLl · 2025-06-08 06:50 Quote from: Thaddy on June 08, 2025, 07:57:01 amQuote from: MarkMLl on June 07, 2025, 08:39:39 pmSecond, Pascal's case statement does not have a mandatory else/otherwise part, but a case expression would have to have one.If you accept that ISO 10206 is an extension to ISO 7185 then, according to the standard, otherwise is mandatory if not all cases are covered. The  compiler throws a warning in all dialects but ExtPas where it should throw an error. It's mandatory in Modula-2 as well, and I always use it as a point of good practice. MarkMLl ---------------------------------------------------------------------- 440bx · 2025-06-08 08:02 Quote from: MarkMLl on June 08, 2025, 08:50:05 amIt's mandatory in Modula-2 as well, and I always use it as a point of good practice. MarkMLl Talking about "good practice"... good practice includes abstaining from posting off-topic material particularly when you and the others have been explicitly asked not to. Keep talking about "good practice"... your behavior and that of others really show how much you care about it. ---------------------------------------------------------------------- Joanna · 2025-06-08 23:03 440bx It is easy to break out early from a case statement just put your code inside a procedure or function and call that from inside the case statement. The procedure/function can contain an exit. ---------------------------------------------------------------------- 440bx · 2025-06-09 00:29 Quote from: Joanna from IRC on June 09, 2025, 01:03:19 am440bx It is easy to break out early from a case statement just put your code inside a procedure or function and call that from inside the case statement. The procedure/function can contain an exit. that solution is obvious but it has the _severe_ downside that the code is all over the place instead of in a single block. ---------------------------------------------------------------------- bytebites · 2025-06-09 01:51 Quote from: 440bx on June 09, 2025, 02:29:48 amthat solution is obvious but it has the _severe_ downside that the code is all over the place instead of in a single block. Why don't you follow your own rule? ---------------------------------------------------------------------- 440bx · 2025-06-09 02:06 Quote from: bytebites on June 09, 2025, 03:51:23 amQuote from: 440bx on June 09, 2025, 02:29:48 amthat solution is obvious but it has the _severe_ downside that the code is all over the place instead of in a single block. Why don't you follow your own rule? I do follow my own rules.  One of them is that if someones asks a question, the polite thing to do is to provide an answer.  I provided a short one because, in this thread, her question is off-topic and consequently so is the answer but, being polite took precedence. If you or her, asks additional off-topic questions then I will inform you or her that there will be no answer because the question is off- topic.  I hope that clarified my rules for you. ---------------------------------------------------------------------- bytebites · 2025-06-09 02:26 Quote from: 440bx on June 09, 2025, 04:06:42 amQuote from: bytebites on June 09, 2025, 03:51:23 amQuote from: 440bx on June 09, 2025, 02:29:48 amthat solution is obvious but it has the _severe_ downside that the code is all over the place instead of in a single block. Why don't you follow your own rule? I do follow my own rules.  One of them is that if someones asks a question, the polite thing to do is to provide an answer.  I provided a short one because, in this thread, her question is off-topic and consequently so is the answer but, being polite took precedence. If you or her, asks additional off-topic questions then I will inform you or her that there will be no answer because the question is off- topic.  I hope that clarified my rules for you. Mark was polite too. So the rule is invent new rule if you want follow a rule. ---------------------------------------------------------------------- 440bx · 2025-06-09 05:33 Quote from: bytebites on June 09, 2025, 04:26:23 amMark was polite too. So the rule is invent new rule if you want follow a rule. You're off topic. ---------------------------------------------------------------------- Joanna · 2025-06-09 07:52 440bx you can put the code in a procedure declared inside the current procedure where the case statement is located. That would definitely not be “all over the place“. If this is not possible I’m curious to see your code. How many lines long is your procedure? ---------------------------------------------------------------------- bytebites · 2025-06-09 08:02 Quote from: 440bx on June 09, 2025, 07:33:30 amQuote from: bytebites on June 09, 2025, 04:26:23 amMark was polite too. So the rule is invent new rule if you want follow a rule. You're off topic. Says forum cop. ---------------------------------------------------------------------- creaothceann · 2025-06-11 18:07 While I'm not that fond of if (littering the code with branches doesn't sound very helpful, unless it is known that the conditions follow a pattern at runtime and aren't random) it looks like a way to save a little bit of typing. I'd rather have a way to ensure that the compiler uses branchless code (conditional moves) when I know that the condition is quite unpredictable... At the moment for simple integer values that involves writing a branchless test that continues with using bitwise operations (with 0 or -1) or multiplications (with 0 or 1). ---------------------------------------------------------------------- Zoran · 2025-06-11 19:46 Quote from: jamie on June 08, 2025, 12:46:40 amThose that don't want it don't need to use it, correct? Absolutely not correct. By the way, I really like the particular feature and if it gets into language, I'll use it a lot. My point is that the quasi argument that "You don't have to use some feature" is always very wrong. Once the new feature is in the language, you can't avoid it -- you will encounter it in the sources and you will need to read and understand this code. So please, never use this argument. ---------------------------------------------------------------------- mika · 2025-06-12 07:50 Quote from: Warfley on June 05, 2025, 10:41:05 pmWas bored and wanted to see how long it takes ... ... and took 15 minutes to create the attached patch for fpc main Get bored for yet another 15 minutes and create proper merger request in gitlab. ---------------------------------------------------------------------- MarkMLl · 2025-06-12 08:10 Quote from: mika on June 12, 2025, 09:50:37 amGet bored for yet another 15 minutes and create proper merger request in gitlab. How about *you* spend five minutes reading the entire thread? If you did you'd find that not only has this been discussed already, but that in the past no less a personage than Sven added the facility to the compiler but for some reason it was slapped down by the rest of the team. MarkMLl ---------------------------------------------------------------------- mika · 2025-06-12 08:38 Quote from: MarkMLl on June 12, 2025, 10:10:15 amHow about *you* spend five minutes reading the entire thread? Deserved. I limit my time on forum to couple hours in week. Have to be selective what to read. I do skip a lot and missed important comments. Warfley's solution looks promising. Sad to hear that it wont see daylight. ---------------------------------------------------------------------- Warfley · 2025-06-12 20:37 Quote from: creaothceann on June 11, 2025, 08:07:54 pmWhile I'm not that fond of if (littering the code with branches doesn't sound very helpful, unless it is known that the conditions follow a pattern at runtime and aren't random) it looks like a way to save a little bit of typing. It's actually not necessarily about saving typing, it's about using expressions instead of statements. Expressions give more guarantees than statements. Expressions can't be empty, meaning a bug such as: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i if condition then  a := Value1else; // note the ; which directly terminates the else branch  a := Value2;which did happen to me more than once, cannot happen with expressions, as every single branch needs to return a value. Also you can make sure that your variable will always be initialized, which is not necessarily the case for statements: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i if condition then  a := 42;// What happens on else branch? But I must admit in Pascal it does not have as much of an advantage as in other languages where there are readonly/constant variables. Take C: Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i const int i = a 1) then a else b and the case expression look very good. I think there is possibly less issues if the latter two could be committed and keep the former a bit longer open for discussion. Maybe split the merge request in two? The tests went as expected. ---------------------------------------------------------------------- Thaddy · 2025-06-14 13:15 @Warfely OFF TOPIC but do you want to have a go at: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i    generic function;So type restrictions expanded for ordinal types? I know my suggestion was more or less approved by PascalDragon. (with a possibly/probably) ( there are several misinformed discussions by forum readers to be found here on the forum about that, ignore these, not on the developers mailing list, though ) This would restrict a generic specialization to any ordinal type, which is very useful. It is in the same category as or It should depend on the ordinal range of the bitness instead. When I tried to do this myself I ran into trouble with 32 bit vs 64 bit true ordinals and gave up. At one point I chose to let it depend on bitness alone and that was probably the wrong choice. It is already listed as  FR for quite some time. ---------------------------------------------------------------------- Warfley · 2025-06-14 22:06 Nah, as I said already, I have a whole list of Merge Requests that I would need to follow up on if I had the time. I just did this because it was easy, just a few hours, but even that was more time than I had available already. That said, it would be definitely useful to have something like this ---------------------------------------------------------------------- jamie · 2025-06-15 15:49 Quote from: Warfley on June 15, 2025, 12:06:22 amNah, as I said already, I have a whole list of Merge Requests that I would need to follow up on if I had the time. I just did this because it was easy, just a few hours, but even that was more time than I had available already. That said, it would be definitely useful to have something like this I know you are having fun dangling that caret with a big smile on your face, but please I am almost out of breath panting waiting for that feature! ---------------------------------------------------------------------- Fibonacci · 2025-06-15 16:04 Quote from: jamie on June 15, 2025, 05:49:30 pmI am almost out of breath panting waiting for that feature! Chill, it wont get merged. Its already been rejected, at least in its current form. If it ever gets accepted, it will have to be nerfed first to make sure FPC doesnt accidentally become too competitive with Delphi. Most likely it will be reduced to just a bare "if" (current proposal is much more than that) in the form of an intrinsic "IfThen". Give it a few years, we'll see. ---------------------------------------------------------------------- MarkMLl · 2025-06-15 16:06 I had something just yesterday which cried out for it: a point in a drawing which for cosmetic reasons had to be moved either upwards or downwards depending on where it was relative to some other point. Now, I know that I could have done that by subtracting, applying the Sign() function, and multiplying the result by the fudge distance required. But on the balance, keeping things readable mandated an if- then-else statement with almost-identical expressions in the two legs. All of which also made me wonder about efficiency: in principle at least the less-readable implementation using Sign() should be more efficient since there would be fewer jumps and pipeline stalls. MarkMLl ---------------------------------------------------------------------- munair · 2025-06-16 05:37 Quote from: Warfley on June 05, 2025, 10:41:05 pmWas bored and wanted to see how long it takes to build something like that: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var  s: string;begin  s := if 0 < 1 then 'Foo' else 'Bar';  WriteLn(s);end. I've been working on something similar for the SharpBASIC compiler, but instead of using IF in an expression, a LET statement is used allowing for one or more 'on' branches: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i let s   on x < y is "Foo";  on x > y is "Bar" else "Nothing";endprint(s); It differs from a case/switch block in that it's purely an assignment statement. This construct clearly separates assignment from boolean evaluation. ---------------------------------------------------------------------- Thaddy · 2025-06-16 07:04 @munair I am repeating myself, but really, Warfely's suggestion is better than the already (main) possible:Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$mode objfpc}{$modeswitch implicitfunctionspecialization}{$if fpc_fullversion < 30301}{$error this version requires fpc331 or higher}{$ifend} uses sysutils; // contains generic ifthen for some years.begin  writeln(ifthen(0 > 1,'Must be true', 'Suppose it is false'));  writeln(ifthen(0 < 1,'Must be true', 'Suppose it is false'));  writeln(ifthen(0 > 1,true, false));  writeln(ifthen(0 < 1,true, false));end. Try leaving out the {$modeswitch implicitfunctionspecialization} With due respect, you do not seem to fully grasp what the discussion is about. It is about making such things a compiler intrinsic. Whatever syntax is decided. For most people, though, the above will suffice. The modeswitch will likely disappear in a real FPC 4.0 release. (because it will be added to at least mode delphi) I wrote the generic ifthen. not a big feat, Implicit specialization was not possible at the time. Good example of how the language features evolve over time and solutions are mutually beneficial. ---------------------------------------------------------------------- Warfley · 2025-06-16 10:53 Quote from: munair on June 16, 2025, 07:37:37 amI've been working on something similar for the SharpBASIC compiler, but instead of using IF in an expression, a LET statement is used allowing for one or more 'on' branches: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i let s   on x < y is "Foo";  on x > y is "Bar" else "Nothing";endprint(s); It differs from a case/switch block in that it's purely an assignment statement. This construct clearly separates assignment from boolean evaluation. This wouldn't work for multiple reasons, first, is is already defined as an operator, meaning it can't be used to follow up on an expression. Especially in this case where it would introduce additional ambiguity: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i on MyObject = OtherObject is TMyClassIn this case OtherObject is TMyClass is a perfectly normal expression. Second in Pascal you can't define variables in the code section meaning such a let construct is also not possible. Lastly the FPC team does not like the introduction of new keywords, which means adding a new keyword for this is also not an option. Looking at the keywords available, I don't really see a good syntax option here. Aside from that, if it's only for assignment it's quite limiting, as one of the main usecases for this is using it in function parameters if you don't want to introduce a new variable. If you just do a grep for IfThen in the Lazarus sources, you'll find that around half the use cases of the current IfThen function is not as an assignment. ---------------------------------------------------------------------- munair · 2025-06-16 11:54 Quote from: Warfley on June 16, 2025, 12:53:17 pmSecond in Pascal you can't define variables in the code section meaning such a let construct is also not possible. In SharpBASIC definitions are also not allowed in the code section, similar to Pascal, so s must be defined first: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i dim s:str;dim x, y:int;main do  let s    on x < y is "Foo";    on x > y is "Bar" else "Nothing";  end  print(s);end  Like I said, it's an assignment, but I get the idea of having something like this implemented as an intrinsic. ---------------------------------------------------------------------- avk · 2025-07-31 13:40 Delphi ternary operator: https://blogs.embarcadero.com/coming-in-rad- studio-13-a-conditional-ternary-operator-for-the-delphi-language/ ---------------------------------------------------------------------- Thaddy · 2025-07-31 13:55 I understand from the comments on the bugtracker that a commit may be pending..... https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1037 The comments seem to suggest that it is by now more than a MR. ---------------------------------------------------------------------- bytebites · 2025-07-31 15:27 Pascaldragon once implemented it, but it was rejected. Sad for double work. Principle, which does cause harm is not principle. ---------------------------------------------------------------------- PascalDragon · 2025-07-31 19:17 Quote from: bytebites on July 31, 2025, 05:27:42 pmPascaldragon once implemented it, but it was rejected. Sad for double work. Principle, which does cause harm is not principle. Nowadays I'd implement as if then else instead of a magical IIF(, , ) intrinsic (as I had done back then) anyway. ---------------------------------------------------------------------- jamie · 2025-08-01 22:28 Still waiting for it!  Jamie ---------------------------------------------------------------------- marcov · 2025-08-02 10:39 I liked the IIF() syntax more, but anything is better than yet another redundant syntax, so then I'm fine with functional if then else. ---------------------------------------------------------------------- MarkMLl · 2025-08-02 10:55 Quote from: marcov on August 02, 2025, 12:39:53 pmI liked the IIF() syntax more, but anything is better than yet another redundant syntax, so then I'm fine with functional if then else. Speaking personally, I don't like conflating functions and control structures. MarkMLl ---------------------------------------------------------------------- Gustavo 'Gus' Carreno · 2025-08-04 08:19 Hey Y'All, According to what Michael commented on the MR, since it's being adopted by Delphi, at least the if..then..else is being accepted. I'm still unsure about the inclusion of the case and the try..except, for which I left a comment for Michael to clarify their inclusion. I'll let him voice his opinion on the MR. But I would really like that all three would be merged, that's for sure !! Cheers, Gus