Hello together!

Time for the next flame. I've attached a patch which implements an "if Condition then ThenExpr else ElseExpr"-expression for those that want to play around with it. It follows the same principles as the yet-to-be-renamed IfThen() (namely that the type is determined by the ThenExpr) as it's just a different syntax with the same (copy & pasted) code behind it...

Note: this patch *might* also work with 3.0.0 or even 2.6.4...

Regards,
Sven

What a pity that you removed IfThen(). IMO it was a great addition.

Ondrej

You were almost 10 years ahead :)

https://blogs.embarcadero.com/coming-in-rad-studio-13-a-conditional-ternary-operator-for-the-delphi-language/

Ondrej

Ondrej Pokorny via fpc-devel schrieb am
Do., 21. Aug. 2025, 23:49:

Oxygene already had it for longer which is where I had the idea from 😅

Regards,
Sven

Hi,

The new syntax has strong Python vibes to me. This is where I saw/used this the most. Which is not necessarily a bad thing. My code is usually very oldschool and I tend to avoid most of the "modern" bells & whistles, as I have a firm belief they hinder long-term maintainability, or they're simply eye-sore (mainly that Delphi inline variable declaration comes to mind) but this is one of the "newschool" syntax things which I'd gladly use myself.

Charlie

On Aug 24, 2025 at 3:28:45 PM, Karoly Balogh via fpc-devel <

I think they added a IfThen generic which can be implicitly specialized now so you can do things like:

  s := IfThen(p  nil, 'valid', 'nil’);

vs

  s := If p  nil then 'valid' else 'nil';

It’s almost easier to read. I’m not sure I’d like the have if-statements confused with expressions when scanning code either. At least the C version is more terse but that one can be hard to identify also. All in all I think IfThen is actually pretty good.

But they're not 100% compatible, are they? IfThen evaluates both the true and the false parameter, while the 'if' statement doesn't. For example:

s := IfThen(b  0, a div b, 999)

Will raise a division by zero exception, if b is 0, while

s := if b  0 then a div b else 999

won't.

Nikolay

On Aug 26, 2025 at 3:49:43 AM, Nikolay Nikolov via fpc-devel <

I think if the call was inlined it wouldn’t but otherwise it would. FPC can’t reliably inline either so you wouldn’t want to risk that. If that’s a concern then IfThen could be an intrinsic. It’s basically just a macro to a if statement with an assignment. Extremely simple thing to implement.

Inlining must not change the behavior.

Nikolay is right, that full or part evaluation is an important difference here.

Another is the unbelievable (well at least for most users) complexity of an if-expression for a Pascal compiler, as it has to determine the result type.

Mattias

Hairy Pixels via fpc-devel schrieb am Di.,
26. Aug. 2025, 09:53:

As said IfThen evaluates both sides no matter the result of the expression. The if-expression will not. Thus is a very important difference. Also there *will* be the if-then-expression, the question is only when the merge request is finalized enough (I currently can't check, so I can't comment on any progress there).

Regards,
Sven

Hairy Pixels via fpc-devel schrieb am Do.,
28. Aug. 2025, 09:55:

That's wrong. Inlining does *not* change side effects (and if it does that is considered a bug), so parameters are evaluated before the inlined function's code is executed.

If that’s a concern then IfThen could be an intrinsic. It’s basically just

a macro to a if statement with an assignment. Extremely simple thing to implement.

There had already been an IfThen-intrinisic almost ten years ago, which was then rejected and reverted cause due to its different behavior to a ordinary function would lead to more confusion.

The if-the-expression is just as easy to implement and is now required for Delphi compatibility anyway, so there will not be any discussion about this anymore.

Regards,
Sven

Parameter evaluation order is ub so you cannot rely on that, regardless of inlining. And even though the intrinsic could behave differently it still looks like a regular function call and also might clash with existing similarly named existing function.

On Aug 28, 2025 at 5:10:56 AM, Sven Barth via fpc-devel <

I didn’t realize it was imminent.

What about this:

  if (if x > 10 then 1 else -1) > 0 then
    ;

You can do confusing things like this too right? I don’t think we’re going to avoid confusion with the intrinsic or this syntax.

Op 29-8-2025 om 16:30 schreef Hairy Pixels via fpc-devel:

Determining the type of the nested IF is more complex in this case I guess.

Yes, that would become valid syntax. However, I doubt you're gonna see such code anytime soon, outside of obfuscated code contests (or vibe coded AI slop). Your nested if example is pointless, because it is equivalent to the much simpler:

if x > 10 then
   ;

You're more likely to see things like:

a := if x > 10 then 1 else -1;

instead of

if x > 10 then
   a := 1
else
   a := -1;

At least that's what I see in Rust code, which has a similar "if" as an expression, as well as a "if" as a statement. People who have the tendency to like functional programming tend to prefer the first form.

Every feature can be abused to write ugly code, but this one is not so bad, actually.

Nikolay

On Sep 1, 2025 at 3:44:17 PM, Nikolay Nikolov via fpc-devel <

Yes I agree but in C-like languages I do use it in function parameters just as often. Still feeling like IfThen if made a real intrinsic would be most readable and Pascal-like. Since this new expression exists now making the intrinsic would be extremely trivial.

Hairy Pixels via fpc-devel schrieb am Di.,
2. Sep. 2025, 09:50:

It doesn't matter whether it's trivial or not. An IfThen() intrinsic would have a different behavior from *any* other function-like element and thus would be a bad idea. Thus there will be *no* auch intrinsic.

Regards,
Sven

I don't think this is a good argument:

Write(), Writeln, WriteStr and Str() are also intrinsics with "different behaviour" from all other function, intrinsic or not:

The : formatting for one, and some arbitrarily limited varargs-like behaviour for another.

Yet these are firmly entrenched in pascal.

So at least on these grounds, the IfThen() has as much reason for existence as these "real pascal" functions, in my opinion.

There can be other reasons pro or con, of course.

Michael.

Michael Van Canneyt via fpc-devel schrieb
am Di., 2. Sep. 2025, 14:28:

But that's also not a reason that there should be more intrinsics that behave different from normal functions.
Also none of these you mentioned have a behavior like the IfThen() intrinsic would have and some people might not even know that the parameters can be adjusted with the ":" syntax (or even if they do they might not need to use it; I don't know when I last used that for example), but for IfThen() that is a core part of the behavior.

Regards,
Sven

I agree on that.

I only meant to indicate the particular behaviour is not a reason to refuse a certain intrinsic.
TypeInfo,SizeOf: they take types as argument. This is also different from regular functions.
We have no choice of course, the intrinsics are necessary to be able to deviate from what is "normal" in pascal.

Personally, I think we already have too much intrinsics to begin with;
no matter their behaviour. But that is another discussion entirely...

Michael.

On Sep 4, 2025 at 1:43:23 PM, michael via fpc-devel <

How so? The reason intrinsics are used is because they can’t be replicated at runtime. If you remove them then you lose that functionality entirely.

As I wrote, for some it is needed. No arguments there.

But AFAIK many regular functions such as Length(), Inc/Dec() etc. are also converted to intrinsics.

No doubt for performance reasons, but I'd rather have as little as possible "compiler magic".

Michael.

michael via fpc-devel schrieb am Do., 4.
Sep. 2025, 09:29:

Not performance reasons, but because they need to be usable by many types and thus can't be expressed using ordinary Pascal in a typesafe way. Implicit function specialization would change that, however that would mean the generation of a specialized definition each time it is used in a different unit and for every type.

Regards,
Sven

Why inc() dec() cannot be expressed in a typesafe way ? We have InterlockedIncrement etc, and they do the same thing ?

Implicit function specialization would change that, however that would mean the generation of a specialized definition each time it is used in a different unit and for every type.

As I said, for some it is needed. For Length() that may be the case, as you point out.

In each case, my point of view remains that the less intrinsics we have, the better it is.

Michael.

Michael Van Canneyt via fpc-devel schrieb
am Sa., 6. Sep. 2025, 20:53:

Inc() and Dec() also work with enums which are custom types.

In each case, my point of view remains that the less intrinsics we have, the

better it is.

I agree. Intrinsics should only be added when necessary.

Regards,
Sven

Hi,

Implicit function specialization would change that, however that would mean the generation of a specialized definition each time it is used in a different unit and for every type.

This calls for a space optimizer that removes unnecessary specializations

3 optimizations could one have:

* If the project already has a specialization with the types in any unit, then it will not be generated again

* If two different specialization create the same assembly, then the previous specialization will be reused (bitwise comparison of the code after it has been generated)

* a semantic analysis that determines whether the specialization is actually necessary and then does not generate anything new if it is not.   (e.g. if a function is generic <T: TObject>, but no properties of T are used, but it only cast a result to T (like e.g. a generic TList.get), then it can create the function for TObject once and then never again for T.  )

Best,
Benito

Benito van der Zander via fpc-devel
schrieb am Mo., 8. Sep. 2025, 00:40:

These two are nice and well in theory, but due to units being independent of each other this can in the end only be handled by the linker.

Detecting such is massively complicated.

Regards,
Sven