<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">J. Gareth Moreton via fpc-devel <<a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>> schrieb am Sa., 16. Apr. 2022, 01:33:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actual Pascal calls to FillChar would not change in any way and so <br>
theoretically it won't break existing code.  The only drawback is that <br>
the intrinsic and the internal System functions would have to be named <br>
the same so constructs such as "FuncPtr := @FillChar;" as well as <br>
calling FillChar from assembler routines stilll work, and the compiler <br>
would have to know how to differentiate between the two.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Intrinsic symbols do not participate in overload selection and you can't have both an intrinsic and a function symbol in the same unit. The construct you showed thus *will* fail. </div><div dir="auto"><br></div><div dir="auto">Note: this is not necessarily an argument against doing this, cause with 3.2.0 we did the same with Insert and Delete when they were extended to support dynamic arrays as well, but it needs to be kept in mind. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>