Zweiter versuch RIO vs Tokyo TStringDynArray

[QuickAndDirty]

Zitat von TiGü:

Hat jetzt nur sekundär mit deinen Problem zu tun, aber vielleicht hilft es den einen oder anderen interessierten Leser bei ähnlichen Problemen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

type
  TMyLittleStringArray1 = array of string;
  TMyLittleStringArray2 = TArray<string>;
  TMyLittleStringArray3 = TArray<string>;
  TMyLittleStringArray4 = TMyLittleStringArray1;
  TMyLittleStringArray5 = type TMyLittleStringArray1;
  TMyLittleStringArray6 = array of string;

var
  One: TMyLittleStringArray1;
  Two: TMyLittleStringArray2;
  Three: TMyLittleStringArray3;
  Four: TMyLittleStringArray4;
  Five: TMyLittleStringArray5;
  Six: TMyLittleStringArray6;
begin
//  One := Two; // [dcc32 Error] Project1.dpr(19): E2010 Incompatible types: 'TMyLittleStringArray1' and 'System.TArray<System.string>'
//  Two := One; // [dcc32 Error] Project1.dpr(20): E2010 Incompatible types: 'System.TArray<System.string>' and 'TMyLittleStringArray1'
  One := TMyLittleStringArray1(Two); // geht durch casten
  Two := TMyLittleStringArray2(One); // geht durch casten
  Three := Two; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  Two := Three; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  One := Four; // geht, weil nur Alias und sonst gleicher Typ
//  Five := One; // geht nicht, da durch type Schlüsselwort ein neuer Typ gebildet wird
//  One := Six; // geht auch nicht, weil neuer Typ -> ja, auch wenn bei beiden = array of string steht
end.

Sowas ist wieder ein klassischer Fall von Irrsin der einen Ducktyping vermissen lässt oder?
Gerade beim bilden der SOAP Schnittstelle...