[fpc-pascal] which "managed" result types require extra work?

[Jonas Maebe]

David Emerson wrote:

> Which types do we need to initialize to null/nil/zero/'' when they are a
> function result?

Results of all types (managed or not) need to be set to "empty" if you
want them to return an "empty" result.

> I understand COM-style interfaces are also managed types, do they also
> need a manual initialization to nil if a function result?

Even if they didn't/don't, that would only be an implementation detail.
As a rule of thumb, function results do not contain a predictable value
on function entry.

> Is there any compiler switch or option that we can use to do this
> automatically? (which won't be disabled with any optimization level)

No.

> As a note... practically, this is a huge pain; if I have a record type
> that I use extensively, and then I add an ansistring or dynamic array
> field to that record type, then I'm going to have to look all over my
> code for functions returning that result type, and fix the initialization.

If a record type does not contain an ansistring or a dynamic array, you
also have to initialise results of functions returning such a type to
get them to return a "empty" value. If you add a field that is not a
managed type, you will also have to go through your code to add
initialisation code for that field everywhere.

So I'm not sure how this is different from any other type.


Jonas

PS: there is an intrinsic that can help you in this process: the
"default" intrinsic. Default(TSomeType) returns an instance of a
particular type completely initialised to "empty" (0 for ordinal and
floating point types, empty for strings, nil for pointers etc). You can
assign this to e.g. your function results on entry, so that even when
you add fields (of any type) to records you don't have to add additional
initialisation code.