Eigentlich müsste die Prüffunktion dafür, beim Result, einfach nur zu Funktionsbeginn "vergessen" daß die Variable schon initisialisert ist.
Wenn ich mich recht entsinne, dann hat Danny Thorpe, seinerzeit Compiler-Engineer, mal gesagt/geschrieben, dass die Warnungen vom Code-Generator erzeugt werden und nicht vom Parser. Der Code-Generator weiß somit nicht mehr, dass das Interface ein Rückgabewert war, denn er sieht nur den "var" Parameter vom Typ Interface.
Zitat:
Also einfach den VAR-Parameter wie einen OUT-Parameter behandeln, wenn es mal ein Result war.
Für den Compiler ist
var und
out mehr oder weniger dasselbe.
Out hat nur eine technische Bedeutung bei OleVariants. (Ich nutze persönlich
out aber trozdem zur "Dokumentation").
Zitat:
Aber ob man es nach 15 Jahren schafft das jetzt noch zu reparieren?
Wo ein Wille da ein Weg. Aber der Wille tendiert im Moment mehr zu "wir streichen die Datentypen zusammen".
Eine Warnung in solch einem Fall wäre mehr wert als so manche Warnings, die der Compiler ausspuckt
Eine solche Warnung, vor allem bei dyamischen Arrays würde auch der Delphi
IDE gut tun. Ich erinnere mich da an so manches Performance-Problem, wie z.B. "mit jedem Kompilieren dauert das nächste Kompilieren länger".
Der Grund war Code, der das dynamische Rückgabe-Array nicht abgelöscht und es fleißig mit "SetLength(Result, Length(Result) + 1)" in einer Schleife vergrößert hat (man hätte ja auch die Anzahl vorher bestimmen können).
Pseudocode:
Delphi-Quellcode:
begin
for I := 0 to Items.Count - 1 do
begin
FMyArrayObjectField := Items[I].ToArray;
...
end;
end.
function TMyItem.ToArray: TArray<string>;
begin
// hier das fehlende "Result := nil;"
for I := 0 to Item.ChildCount - 1 do
begin
SetLength(Result, Length(Result) + 1);
Result[High(Result)] := Item.Childs[I];
end;
end;