[fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

[John Doe]

On Sat, Jan 26, 2019 at 7:44 PM Sven Barth via fpc-devel <
fpc-devel at lists.freepascal.org> wrote:

> Changing this behavior would not only be a backwards incompatibility, but
> would also violate the ABI which describes how records shall be passed.
>

On second thought, I definitely agree with you that changing the basic
behavior of the compiler in that regard sounds like an idea that is not
remotely possible due to how it would very likely break large amounts of
existing code. That was a dumb suggestion on my part.

However, I'm also quite simply unaware of any specific realistic scenario
where I would *ever* specify a un-prefixed record in a method (in my own
projects for example I actually haven't used anything but "var" and
"constref" for years, not even just normal const as it doesn't always "do
the trick" I've found), and I do think that on a more broad scope it is
highly unlikely that most existing record methods written in an
"unprefixed" fashion were done that way for any particular or intentional
reason.

Like I suggested earlier, it seems like many people are simply unaware that
FPC's behaviour in that area is completely predictable and fully
*unrelated* to any optimization settings: it just will not, ever, under any
circumstances, pass a record or object without var or const or constref by
reference.

The only guess I have as to *why* they don't know (or maybe even actually
think it's "not that important") is that they (they being, again, the
people who write code like this) are people who originally learned Pascal
with Turbo Pascal where that sort of optimization was far less relevant and
may not have even done anything (as you couldn't even return records or
objects from functions in TP, I don't think.)

Regardless, units like graphmath.pp
<https://github.com/graemeg/lazarus/blob/upstream/lcl/graphmath.pp> from
the LCL (which I know is slightly out of scope here) are quite simply
painful to read. Look at those operator overloads for TFloatPoint! No
const, no inline. In fact only two methods in the entire unit are marked
inline, despite how it's full of very short math functions that should very
clearly be marked as such.

I think there's a LOT of "free" performance-increase potential that
everyone would benefit from lurking in many places, that doesn't require
anything new from the compiler but just for things like that to be remedied.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190126/c7404569/attachment.html>