W1048 Unsichere Typumwandlung obwohl völlig ok

[Der schöne Günther]

Ich habe in einem Projekt zwei Klassen mit ungefähr diesem Konstrukt:

Delphi-Quellcode:

unit MeineUnit;

interface uses System.TimeSpan;

type
   TMyObject = class
   private/protected var
      someInternalField: TTimeSpan;
   public
      constructor Create();
   end;

implementation

constructor TMyObject.Create()
begin
   inherited Create();
   someInternalField := TTimeSpan.Zero; // << W1048
end;

In beiden Units wird die Zeile someInternalField := TTimeSpan.Zero; angekreidet, es sei eine "W1048 Unsichere Typumwandlung von 'TTimeSpan' nach 'TTimeSpan'".

Potz Donner. Was läuft hier verkehrt?

Ich kann das in einem neuen, leeren Projekt mit beiden Units mit 1:1 dem gleichen Inhalt nicht nachvollziehen. Ich bekomme es echt nicht rekonstruiert.

[Uwe Raabe]

Zitat von Der schöne Günther:

Ich habe in einem Projekt zwei Klassen mit ungefähr diesem Konstrukt:

Dann versuch mal, das "ungefähr" zu eliminieren.

[Der schöne Günther]

Die Vereinfachung bezog sich nur auf den geposteten Code. Ich bekomme es mit EXAKT den gleichen Units nicht in einem leeren Projekt reproduziert. Oder habe ich das jetzt falsch verstanden?

Edit:
Die Ursache lag in der Unit welche sich eine Instanz von TMyObject erstellt hat. Sie hatte uses [...], Spring und ebendiese Unit redeklariert in ihrem Interface-Teil (weshalb auch immer) TTimeSpan = TimeSpan.TTimeSpan; .
Wenn ich dort nun ein reines "TTimeSpan" benutze, dann ist es ein Spring.TTimeSpan und kein System.TimeSpan.TTimeSpan, obwohl es eigentlich nur ein Alias ist.

Warum der Compiler nun den Konstruktor anstreicht und nicht die Zeile wo ein Spring.TTimeSpan einer System.TimeSpan.TTimeSpan-Property zugewiesen weiß ich allerdings auch nicht.

Immerhin bin ich die Warnung los.

[Uwe Raabe]

Zitat von Der schöne Günther:

Ich bekomme es mit EXAKT den gleichen Units nicht in einem leeren Projekt reproduziert.

Dann überprüf mal, ob eventuell bei den Suchpfaden irgendetwas zu finden ist, bei dem TTimeSpan neu deklariert wurde.

Also z.B. im interface-Teil wird TTimeSpan aus System.TimeSpan verwendet und im implementation-Teil hängt sowas wie dies dazwischen:

Delphi-Quellcode:

uses
  System.TimeSpan;

type
  TTimeSpan = type System.TimeSpan.TTimeSpan;

[Der schöne Günther]

Siehe mein Edit darüber: Du liegst (wie immer) absolut richtig

Ich würde es einsehen wenn, wie in deinem Beispiel, ein neuer Typ deklariert wird. Hier ist es eigentlich nur ein Alias. Komisch.

[himitsu]

Arbeitest du mit Laufzeitpackages?

Der Typ in im nachfolgenden Package ist nur eine Variable, die beim Laden der BPL die Referenz des aktuellen Typ im ersten Package bekommt.

[Der schöne Günther]

Zitat von himitsu:

Arbeitest du mit Laufzeitpackages?

Nein, nie.

Vielleicht aber liegt es daran dass er von Spring natürlich nicht jedes mal neu kompiliert sondern fertige DCUs nimmt?

[Sherlock]

Zitat von Uwe Raabe:

Delphi-Quellcode:

uses
  System.TimeSpan;

type
  TTimeSpan = type System.TimeSpan.TTimeSpan;

Man darf sich aber schon wundern, wozu das gut ist, oder?

Sherlock

[himitsu]

PS: Das von Uwe war nur ein Beispiel, was wohl im Delphi nicht wirklich so aussieht.


Ein Typ gleichen Aufbaus, der aber nicht mit dem Anderen "kompatibel" ist?
z.B. für Typen, welche eine andere Art von Daten enthalten, aber wo man sich sparen möchte es neu zu definieren.

Delphi-Quellcode:

type
  TMyType = type Integer;

procedure Test(X: Integer); overload;
procedure Test(W: TMyType); overload;

Bei TMyType = Integer; wüsste der Compiler garnicht welche Funktion er nehmen soll.

[Sherlock]

Das ist mir klar, und wenn man einen Bezeichner für den "neuen" Typen verwendet, der nicht für Unmut sorgt zB TSherlockTimeSpan = type System.TimeSpan.TTimeSpan; , ist auch alles Bestens. Aber Spring scheint das ja nicht getan zu haben, darum meine Frage: "Wozu?".

Sherlock