<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Виктор Матузенко <<a href="mailto:vitek03@gmail.com">vitek03@gmail.com</a>> schrieb am Mi., 19. Juni 2019, 16:25:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 19 июн. 2019 г. в 17:10, Marco van de Voort <<a href="mailto:fpc@pascalprogramming.org" target="_blank" rel="noreferrer">fpc@pascalprogramming.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
No. Such guarantees/constraints on a long term basis would paralyse the <br>
project too much. We try to avoid breaking backwards compatibility as <br>
much as possible, but we can't always guarantee it absolutely.<br>
<br>
</blockquote></div><div><br></div><div>Ok, just for clarification: is that "builtin" pitfall required at all? What makes</div><div>Length and Copy special and non-overloadable?</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">They are special because they can also be used with any array type. This isn't something that can be modeled using normal functions. </div><div dir="auto">And all intrinisics behave that way (e.g. Writeln does as well). </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>