<div dir="ltr"><div dir="ltr"><div dir="ltr">On Sat, Jan 26, 2019 at 7:44 PM Sven Barth via fpc-devel <<a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Changing this behavior would not only be a backwards incompatibility, but would also violate the ABI which describes how records shall be passed.</div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.)</div><div><br></div><div>Regardless, units like <a href="https://github.com/graemeg/lazarus/blob/upstream/lcl/graphmath.pp">graphmath.pp</a> 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.</div><div><br></div><div>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.</div></div></div></div>