Array is not empty when entering function

[marcov]

Yes. Doing it this way has the potential to save reallocations.

True, but it can go the other way.

To save the re-alloc, the code must not contain "result := nil". => Which would be the way to initialize result.

Because
   "SetLenght(result, NewLen);"
gives the "managed type not initialized" hint. (which is needed to omit the re-alloc, if the size is kept or changed within bounds that fit current mem alloc)

That is not something that belongs in a language definition, that's the problem with hack solutions around warnings, which are compiler, not language specific.

Anyway, this is why I usually pass large arrays not as result, but as VAR with a boolean indicating success. More or less as TryStrtoInt() That's a habit that I already had with delphi.
 

[Thaddy]

@Zvoni

Better alternative along the lines of DynArrayLength etc in system unit.
Lifted from the compiler code and put into function:

Code: Pascal  [Select][+][-]

1. function DynArrayRefCount(p:Pointer):integer;
2. type
3.   pdynarray = ^tdynarray;
4.   tdynarray = { packed } record
5.     refcount : ptrint;
6.     high : tdynarrayindex;
7.   end;
8. begin
9.   Result := pdynarray(p-sizeof(tdynarray))^.Refcount;
10. end;

Still, don't use it. Although it works the same as DynArrayLength, which is public, even on the same internal record.

[Zvoni]

@Zvoni

Better alternative along the lines of DynArrayLength etc in system unit.
Lifted from the compiler code and put into function:

Code: Pascal  [Select][+][-]

1. function DynArrayRefCount(p:Pointer):integer;
2. type
3.   pdynarray = ^tdynarray;
4.   tdynarray = { packed } record
5.     refcount : ptrint;
6.     high : tdynarrayindex;
7.   end;
8. begin
9.   Result := pdynarray(p-sizeof(tdynarray))^.Refcount;
10. end;

Still, don't use it. Although it works the same as DynArrayLength, which is public, even on the same internal record.

No worries about using it (at least used by me). Don't have any use-case for that.
It's more or less curiosity on my side in case i really do have to investigate something like that.

My thought about checking the RefCount was more along the lines for TS to understand, why his second call to his Function holds the Length of the first call:
Because Result is By Ref, and he has a variable outside holding that reference

[Thaddy]

Actually, this hack may be low risk, because it follows code that is otherwise public in the compiler.
Just don't use it in production.
That said: I have a use case for it, so I keep it in my toolbox.

(Made a feature request, because as you imply it is a great debugging tool aside from the debugger supporting it.)

[LemonParty]

Remark Function results are treated as pass-by-reference parameters. That is especially important for managed types: The function result may be non-nil on entry, and set to a valid instance of the type.

This explains things. Initially I suspected that compiler automatically treat managed types.
Thank you for help.