On Thu, Jul 20, 2023 at 7:59 AM Sven Barth via fpc-devel
wrote:
> It is indeed by design that not every integer type is a suitable index
> variable for a for-loop. In this case that a 64-bit variable can't be used on
> a platform with less than 64-bit width. The same is probably also true for
For const param, it is well documented that the value (that includes the
variable that is passed) must not be changed.
But for "var param"?
Well maybe, but not explicit
https://www.freepascal.org/docs-html/ref/refsu68.html#x184-20800014.4.5
>> Open parameters can be passed by value, by referenc
On Thu, 20 Jul 2023, Martin Frb via fpc-devel wrote:
For const param, it is well documented that the value (that includes the
variable that is passed) must not be changed.
But for "var param"?
Well maybe, but not explicit
https://www.freepascal.org/docs-html/ref/refsu68.html#x184-20800014.4
On 20/07/2023 19:24, Michael Van Canneyt via fpc-devel wrote:
It's IMO probably better to outright forbid passing open array by
reference.
printing length(a) after x:=Nil; gives 10, which is simply wrong.
The open array is not the same as the dyn array.
It is at any point just a slice of
Michael Van Canneyt via fpc-devel schrieb
am Do., 20. Juli 2023, 19:24:
>
>
> On Thu, 20 Jul 2023, Martin Frb via fpc-devel wrote:
>
> > For const param, it is well documented that the value (that includes the
> > variable that is passed) must not be changed.
> >
> > But for "var param"?
> >
> >
On Thu, 20 Jul 2023, Sven Barth via fpc-devel wrote:
It's IMO probably better to outright forbid passing open array by
reference.
There are valid use cases for that. E.g. multiply a slice of a dynamic
array by two or whatever. And forbidding var would solve nothing, see
below.
printing
