how to safely bypass Delphi Error: “types of formal and actual parameters must be identical”

Question

I need a way to write a generic procedure to act upon an object type or any of its descendants.

My first attempt was to declare

procedure TotalDestro         


        

Answer 1

can you improve this Delphi source code so that the warning would not be needed?

Yes, you can get a type safe way to avoid the compiler error. In the newest Delphi 10.4 Sidney, the FreeAndNil procedure has been changed into this:

procedure FreeAndNil(const [ref] Obj: TObject);
var
  Temp: TObject;
begin
  Temp := Obj;
  TObject(Pointer(@Obj)^) := nil;
  Temp.Free;
end;

It is type safe for objects and will catch errors when passing an interface reference for example.

The way to pass a parameter by const [ref] means that the parameter is passed by reference. Without the [ref] attribute, parameters with size equal and smaller than a pointer would otherwise be passed by value.

Here, even though the object is passed as a constant, the reference will be modified. In that sense, it is not a perfect declaration, but will do its job better than the former implementation.

From New features in Delphi 10.4:

This means that incorrect usage of FreeAndNil will now cause a compiler error. In the past, incorrect usage would not be caught, leading to difficult bugs. Note that although the parameter is declared as const, the by-reference variable is indeed modified.

A new, but ‘not as bad’, class of incorrect calling is possible with this declaration of FreeAndNil: the method can be called passing in properties or a method result, as well as cast expressions, a type’s implicit conversion to TObject, etc. The nil-ed value will then be the temporary variable in the expression.

Answer 2

I've written about this before, using an example very similar to Lasse's:

• Delphi Q&A: Why must the types of actual and formal var parameters be identical?

Unless you're writing an assignment statement to change the value of the input parameter itself, and not just one of its properties, you shouldn't pass a parameter by reference in the first place.

If you are writing an assignment statement to change the parameter's value, then the compiler message really is true, and you should heed it.

One reason for needing to by-pass the error is when you're writing a function like TApplication.CreateForm. Its job is to change the input parameter's value, and the type of the new value varies and cannot be determined at compile time. If you're writing such a function, then your only option with Delphi is to use an untyped var parameter, and then there is extra burden on both the caller and the receiver to make sure everything goes right. The caller needs to make sure it passes a variable that is capable of holding values of whatever type the function will put in it, and the function needs to make sure it stores a value of a type compatible with what the caller requested.

In the case of CreateForm, the caller passes in a class-reference literal and a variable of that class type. The function instantiates the class and stores the reference in the variable.

I don't think very highly of either CreateForm or FreeAndNil, largely because of the way their untyped parameters sacrifice type safety in return for comparatively little extra convenience. You haven't shown the implementation of your TotalDestroy function, but I suspect its var parameter will ultimately provide the same low utility as in those other two functions. See my articles on both:

• When should I use FreeAndNil?
• Why shouldn't I call Application.CreateForm?

Answer 3

Let's examine what you want to do.

You want to call a method that takes X, passing in an object of type Y, where Y is a descendant of X. The snag, the parameter is a "var" parameter.

Let's analyze what you could do if that was possible.

type
    TBase = class
    end;
    TDescendant = class(TBase)
    end;

procedure Fiddle(var x: TBase);
begin
    x := TDescendant.Create;
end;

type
    TOtherDescendant = class(TBase)
    end;

var a: TOtherDescendant;
a := TOtherDescendant.Create;
Fiddle(a);

Uh-oh, now a no longer contains an instance of TOtherDescendant, it contains an instance of TDescendant. That probably comes as a surprise to the code that follows the call.

You must not only consider what you intend to do with the syntax you propose, but effectively what you could do with the syntax.

You should read Eric Lipperts excellent blog post about similar issues in .NET, found here: Why do ref and out parameters not allow type variation?.

Answer 4

In addition to what Lasse wrote, which is quite correct, most of the time you don't want to pass an object to a var parameter anyway.

An object is a reference type. What you see as the object is actually a reference to it. You would only want to pass an object reference to a var parameter if you wanted to change your object out for a new object. If you just want to be able to modify the members of the object, then you can do that by simply passing it to a normal parameter. Make method call take a TMyObject parameter instead of a var TMyObject parameter and it should work.

Of course, if you really are replacing the object, then feel free to disregard all this, and see Lasse's answer.