Naja, logisch betrachtet magst du ja Recht haben, aber ein Record, wenngleich er auch nur einen einzigen Wert beinhaltet, wird vom Compiler nunmal als Record betrachtet und unterliegt somit den Typenbeschränkungen eines solchen.
Ein Record, der nur einen String beinhaltet, ist immer noch ein Record und kein String. Das macht aber auch irgendwie Sinn, denn es ist somit in jedem Fall zu 100% klar, wie sich dieser verhält. Stell dir mal vor, du hast folgenden Record:
Delphi-Quellcode:
TMyRec = record
Value: String;
class operator Implicit(AValue: String): TMyRec;
end;
Und jetzt weißt du diesem Record einen String-Wert zu. Was soll denn jetzt passieren? Soll er den Operator, oder den impliziten Zuweisungsbefehl verwenden? Aber okay, sagen wir jetzt mal, dass es eindeutig sei und er sich für eins von beiden entscheiden würde. Dann fällt uns ein, dass wir am Record noch einen Zweiten Wert benötigen, und ändern diesen entsprechend ab. Und jetzt kompiliert das gesamte Programm plötzlich nicht mehr, bzw. es macht Blödsinn (je nach dem, was vorher passiert ist)? Ich denke nicht, dass das eine sehr sinnvolle Spracherweiterung wäre. Die extrem wenigen Fälle, wo das wirklich sinnvoll wäre, müssten dann mit enormem Programmieraufwand bei allen anderen eingebüßt werden.
Noch nicht einmal fände ich es Sinnvoll, wenn Arrays der Länge 1 mit entsprechenden Variablen kompatibel wären, und das käme sicher noch mit weniger Problem einher.
Pssst: Record ... kein Array (ja, ich weiß dass für Delphi Records auch nur Arrays mit nur einer Ebene sind, zumindestens bei den Funktionen zur Initialisierung des Speichers)
Najaaaaa, wenn du von statischen Arrays redest, dann vielleicht. Nur können ja statische Arrays aus genau dem selben Grund keine Standardwerte haben. Und dynamische Arrays bekommen nur ein offenes Array als Standardwert, das am Anfang der Methode zu einem dynamischen Array konvertiert wird.