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

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.