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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
