[fpc-devel] Overloading standard functions

[Marco van de Voort]

Op 2019-06-19 om 15:55 schreef Виктор Матузенко:
> First, where would be the breakage? Now it works with and without 
> overload?
>
> If I write a unit that overloads the Pos function and code that uses 
> the unit
> and calls standard version of Pos without namespace prefix, than this code
> will be broken if Pos becomes builtin.
>
> (It just will not compile the code and the error "Incompatible type" 
> is not clear
> report the real problem.)
>
Possibly, yes.

> Now the cross unit overload does work for functions declared with the 
> "overload"
> keyword and does not without.

Yes. Partially to signal you are aware that there is a prior function, 
and you want to put it "next" to it for overloading rather than override it.

>
>
>     Second, while the chances are low, there are no guarantees. Avoid
>     overly
>     complex layering of the same symbol if you are afraid of this.
>
>
> I am not a gambler, I ask what is guaranteed.
>
> The Pos is just an example. I can change it to any other symbol: Foo,
> Default, Writeln, GetHash, DoSomething, StrToUtf8 etc. My general
> question is: as a library developer which symbols can I declare to be sure
> that user of the library will not face conflicts with standard 
> declarations,
> FPC RTL etc (and how to do the declarations properly)?

No. Such guarantees/constraints on a long term basis would paralyse the 
project too much. We try to avoid breaking backwards compatibility as 
much as possible, but we can't always guarantee it absolutely.

Over very long periods you might need to occasionally make changes to 
your sources. Just like e.g. Delphi

Since built-ins require compiler modification, you are however pretty 
safe during a compiler major cycle, since the compiler modifications 
merged are mostly fixes, and rarily dialectal changes.

Overriding identifiers used in system/sysutils/classes is asking for 
trouble. Something like POS() is in system since forever, so simply 
don't do that if you want to be future proof.

> The answer I see: none because any identifier may become "builtin",

> start to hardly conflict with any declarations with the same name and
> become PITA for code maintainer.
>
No, since the default is that the local declaration overrides the system 
definition.

So only if you overload an RTL procedure, and then that RTL procedure is 
changed to builtin, you get in to problems.

The number of builtins is low, and all recent ones were not RTL 
procedures before. At least not general ones like POS().

So IMHO this goes way to far into the realm of the hypothetical, since I 
can't remember an actual case when it happened.