Undocumented compiler directive ?

[440bx]

Just playing around, I came across the fact that {$ifend} seems to be an "undocumented" synonym of "$endif" as the following short program shows:

Code: Pascal  [Select][+][-]

1. {$APPTYPE CONSOLE}
2.  
3.  
4. program CompilerDirectives;
5.  
6. const
7.   AConst = 1;
8.  
9.  
10. begin
11.   { using endif                                                               }
12.  
13.   {$ifdef FPC }
14.     {$if AConst = 3}
15.       writeln('AConst = ', AConst);
16.     {$endif}
17.   {$endif}
18.  
19.   {$ifdef FPC}
20.     {$if AConst = 1}
21.       writeln('AConst = ONE');
22.     {$endif}
23.   {$endif}
24.  
25.  
26.   { using ifend                                                               }
27.  
28.   {$ifdef FPC }
29.     {$if AConst = 3}
30.       writeln('AConst = ', AConst);
31.     {$ifend}
32.   {$ifend}
33.  
34.   {$ifdef FPC}
35.     {$if AConst = 1}
36.       writeln('AConst = ONE');
37.     {$ifend}
38.   {$ifend}
39.  
40.   readln;
41. end.              

[Thaddy]

AFAIK it is documented. It is also Delphi compatible.

EDIT
In the latest docs it is not documented. Seems a regression.
The preferred way to close $IF is $IFEND, not $ENDIF, but both can be used.
Order is:
{$IFDEF/$ENDIF} but NOT $IFEND
{$IF/$IFEND} but ALSO $ENDIF
But $ENDIF and $IFEND should be compatible if, and only if {$IF} is used, so plz file a bug against documentation.

[MarkMLl]

There's something wrong here. Newly created Lazarus project using trunk:

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   {$IFDEF UNIX}
7.   cthreads,
8.   {$ENDIF}
9.   Classes
10.   { you can add units after this };
11.  
12. begin
13. end.
14.  

I'm pretty sure I've always used $endif, going back to Turbo Pascal and before. $ifend is the aberration.

MarkMLl

[Thaddy]

I'm pretty sure I've always used $endif, going back to Turbo Pascal and before. $ifend is the aberration.

MarkMLl

Turbo pascal doesn't know $IF , Mark.... Only $IFDEF
Also at least D1 and D2 do not know about {$IF}
Defines with conditional expressions like using $IF defined() or declared() were introduced in a later delphi version.

[MarkMLl]

I'm pretty sure I've always used $endif, going back to Turbo Pascal and before. $ifend is the aberration.

MarkMLl

Turbo pascal doesn't know $IF , Mark.... Only $IFDEF

Yes, and the standard way of closing conditionals is endif.

MarkMLl

[Thaddy]

I'm pretty sure I've always used $endif, going back to Turbo Pascal and before. $ifend is the aberration.

MarkMLl

Turbo pascal doesn't know $IF , Mark.... Only $IFDEF

Yes, and the standard way of closing conditionals is endif.

MarkMLl

NO it is $IF/$IFEND. I will search for the initial introduction of the feature.
It was done on purpose to resolve confusion with closing $IFDEF and add readability.
They actually introduced a bug by accepting $endif for $if.

[MarkMLl]

NO it is $IF/$IFEND. I will search for the initial introduction of the feature.
It was done on purpose to resolve confusion and add readability.
They actually introduced a bug by accepting $endif for $if.

If it's /strictly/ for $if then that's fine, but other combinations should result in errors to reduce potential confusion.

MarkMLl

[lucamar]

Yes, and the standard way of closing conditionals is endif.

Not all conditionals, buf $IFDEF ones (which were the only ones at the time). That's (probably) why they chose a new word ($IFEND) to close the then new $IFs. Though IMHO it wasn't a specially good idea ...

Then, as always happens, they relaxed the sintax and you could mix-and-match however you wanted so instead of a unique, clean construct you now (still?) can find any odd combination, leading to the confussion they were trying to avoid in the first place

ETA: Forgot to add; in case anyone's looking for it, $IF was introduced in Delphi 6 (w/out $IFEND, IIRC; I think that was added in D7)

[Thaddy]

They did not relax the syntax, but IMHO introduced a bug in their parser....
I am not the only one of that opinion. Has been discussed in the past.
I think Lucamar is right about the versions. It also explains why $ENDIF can still be parsed because of backwards compatibility reasons between D7 and D6. That is a valid reason, although very unfortunate.

[Thaddy]

If it's /strictly/ for $if then that's fine, but other combinations should result in errors to reduce potential confusion.

MarkMLl

I totally agree.

[lucamar]

I think Lucamar is right about the versions. It also explains why $ENDIF can still be parsed because of backwards compatibility reasons between D7 and D6. That is a valid reason, although very unfortunate.

Note that one rationale for $ifend was precisely backwards compatibility, so you could compile source containing $if...$elseif...$ifend with, say, Delphi 5 by surrounding the block with e.g. {$IFDEF D6UP}...{$ENDIF}, so I might be wrong and $ifend might have been introduced in D6 along with $if.

I jumped straight from D5 to D7 so my knowledge of D6 is rather sketchy

[marcov]

In some later version (XE3?) Delphi allowed  endif as ending for $IF.

For backwards compatibility there is a switch:    {$LEGACYIFEND ON}

[Thaddy]

In some later version (XE3?) Delphi allowed  endif as ending for $IF.

For backwards compatibility there is a switch:    {$LEGACYIFEND ON}

XE4 http://docwiki.embarcadero.com/RADStudio/Sydney/en/Legacy_IFEND_(Delphi)
and
http://docwiki.embarcadero.com/RADStudio/Sydney/en/IFEND_directive_(Delphi)
I find that rather disturbing.
Ratio is that $IF greatly differs from $IFDEF, which, to my mind, warrants a different closing.
Anyway, my code always uses  $IFEND for $IF blocks and $ENDIF for $IFDEF/$IFOPT blocks.
Reason is simply readability: if I encounter a $IFEND I know there should be a $IF somewhere up. If I encounter a $ENDIF I know I should look for a $IFDEF/$IFOPT.
It is really a pity that got lost. Well, no quality control anyway overthere...
Introducing that "legacy" define is a gotspe 
Looks to me a parser rewriite and document a bug as a feature under false pretences.
As I wrote: I am not the only one who noticed this.

And I also remember that for $IFOPT a $OPTEND/$ENDOPT was suggested 

[PascalDragon]

Just playing around, I came across the fact that {$ifend} seems to be an "undocumented" synonym of "$endif" as the following short program shows:

The $IFEND-directive was introduced by Delphi together with the $IF-directive and one needed to close a $IF with a $IFEND while a $IFDEF continued to be closed with a $ENDIF. Later Delphi versions (XE3 or so) relaxed this so that $ENDIF can be used with $IF as well.

FPC on the other hand got support for $IF rather soon and never had the restriction of $IF requiring $IFEND (or for that matter $IFDEF requiring $ENDIF), cause $IFEND is simply an alias to $ENDIF. $ENDIF is considered the main terminator of a conditional clause with $IFEND flying under the radar and existing mostly for Delphi compatibility which might explain why it was never documented.

So if you want, you can raise a bug report about $IFEND missing from the documentation, but in the end it's merely an alias for $ENDIF.

[440bx]

So if you want, you can raise a bug report about $IFEND missing from the documentation, but in the end it's merely an alias for $ENDIF.

I'll file a bug report just because I believe its existence should be mentioned even though I can see that it is a rather unimportant element of the preprocessor.