[fpc-pascal] Compiler option to check return value ignorance

[Vinzent Höfler]

Joost van der Sluis wrote:

> Ok, so I misunderstood you. You want that the compiler complains if you
> don't assign the result of a function. While that can be done, I don't
> think you want that.

Well, don't decide for others, please. I am a stupid programmmer, I am 
making mistakes all the time, and any feature that could possibly stop 
me from making such is - in my opinion - a useful feature.

I *wanted* it, even have used that feature for years - until "inherited 
Create" came disguised as a function. Unfortunately {$X} can't be used 
locally and always accounts for the whole compilation unit, so you can't 
even use it to temporarily switch on the extended syntax in the few 
places where it would be needed (like I sometimes turn off range checks 
locally) and any other attempts to circumvent that problem just failed.

I just tested again and found something weird. Turning off "Extended 
Syntax" actually disables compilation of constructors at all, so it 
wasn't even only a problem with the "inherited Create" as I remembered.

Look at this:

-- 8< -- snip --
{$MODE OBJFPC}
{$X-}
program
    Ext_Syntax;

type
    Foo = class (tObject)
    public
       constructor Create;
    end;

constructor Foo.Create;
begin
    inherited Create;
    if Assigned (inherited Create) then {null};
end;

var
    A : tObject;
begin
    A := Foo.Create;
end.
-- 8< -- snip --

Compiles fine with {$X+} (line 2). Now let's turn extended syntax off as 
shown and wonder:

|ext_syntax.pas(16,4) Error: Illegal expression

Ok, line 16 is the one with the "inherited Create" on its own. Meets the 
expectation, although it might not be intuitive, but well, even 
constructors can fail, so it might not even be the worst idea to check 
that. ;)

Workaround in the line 17 (dummy test) seems to compile though, so let's 
disable line 16 completely:

|ext_syntax.pas(15,1) Error: Operation ">" not supported for types
|"Pointer" and "Pointer"

Huh? Line 15? The "begin" line?

This happened a couple of years ago with 2.0.0, still happens with 
2.0.2. Haven't given it a shot in 2.2.x yet, but at least now I remember 
why I had to turn on extended syntax for the whole project back then.

> This functionality is used far too often, and those
> warnings would become very annoying.

It might not be common sense anymore, but the term "function" is often 
overloaded as a "subroutine without side-effects". Means, if you don't 
interprete the return value you may as well not call it at all.

Of course, in practice, far too many "functions" have side-effects and 
often it's just the side-effect you need. But that doesn't mean that 
{$X-} wouldn't be useful at all.


Vinzent.