Methoden-Parameter soll Referenz, aber kein nil sein können

[Meflin]

Das Feature, was du hier eigentlich willst, sind Nullable Types. Aber eigentlich egal, auch das kann Delphi nicht
(Andere Sprachen lösen das Problem, indem sie gleich auf das Fail-by-Design Konstrukt von Nullwerten verzichten... siehe z.B. Options in Scala).

In deinem Fall kann man nur sagen: In den Methodenkommentar/Doku schreiben, dass null nicht erlaubt ist, und fertig. Alles andere ist verschwendete Zeit

[jfheins]

Kurze Antwort: Geht nicht.
Lange Antwort:

Zitat von Meflin:

Das Feature, was du hier eigentlich willst, sind Nullable Types.

Glaube ich nicht. Es klingt eher nach nicht-nilbaren Referenztypen (bzw. non-nullable reference types)

Da wird auch schön erklärt, dass das nachrüsten von denen nicht unter beibehaltung von Kompatibilität möglich ist. Der Speicher für ein neues Objekt muss ja erst alloziert werden. In diesem Moment wird der Speicher mit Nullen gefüllt. Wird der Thread genau danach unterbrochen, kann ein anderer Thread das Objekt beobachten. Referenztypen haben damit standardmäßig den Wert nil (weil eben ein 0x00000000 im Speicher steht) und Wertetypen ebenfalls 0 oder 0.0
Es ist eben kein Zufall, dass das Bitmuster 0x00000000 für alle Typen einen gültigen Wert darstellt.

Design by contract trifft eigentlich schon sehr genau das, was der TE will:

Delphi-Quellcode:

require
  aMyReference <> nil;

davor schreiben. Entweder kann der Compiler durch Codeanalyse feststellen, dass der Parameter niemals zu nil werden kann. Oder er wirft einen Fehler und zwingt den Programmierer eine entsprechende Prüfung einzubauen. (Wahrscheinlich im Fall = nil eine Exception werfen...) Und ja, die Prüfung geschieht bereits zur Compilezeit, soweit möglich. Genau so wie der Compiler ja auch schon ermittelt "Variable x wird ein Wert zugewiesen, aber niemals benutzt" kann er auch nil-Referenzen verfolgen und eine "Vertragsverletzung" feststellen.

Ich finde aber auch die Argumentation schlüssig, dass ein nicht-nilbarer Referenztypen (bzw. non-nullable reference type) nicht viel zur Sprache beiträgt. Gäbe es diesen Typen, müsste sich diese Anforderung ja nach oben hin ausbreiten. Die Variable, die ich hinen stecke, müsste ja genau so nicht-nilbar sein. (Ähnich wie in Java: Ich muss Exceptions entweder fangen oder deklarieren dass die Methode diese werfen kann)
D.h. ich habe den Null-check eben weiter oben in der Hirarchie, aber letztlich nicht gespart.

P.S.: Zusammenfassung aus dem Link oben:

Zitat:

So, long story short: non-nullable reference types is a great idea, but as a practical manner, the objections to implementing it now are enormous. Non-nullability is the sort of thing you want baked into a type system from day one, not something you want to retrofit in 12 years later. Keep that in mind the next time you design a new type system!

[Der schöne Günther]

Zitat:

Design by contract trifft eigentlich schon sehr genau das, was der TE will:

Ja, nachdem ich jetzt nochmal das kürzliche Thema Verträge für Delphi / Design by Contract gelesen habe, merke ich das auch

[himitsu]

Zwar nicht im Compiler, aber zur Laufzeit sollte es gehen?

Delphi-Quellcode:

type
  TSimpleNonNullable<T> = record
    class operator Implicit(const Value: TSimpleNonNullable<T>): T; inline;
    class operator Implicit(const Value: T): TSimpleNonNullable<T>; inline;
    class procedure Check(const Value: T); inline; static;
  public type
    ENonNullable = class(Exception);
  private
    FValue: T;
  end;

{ TSimpleNonNullable<T> }

class operator TSimpleNonNullable<T>.Implicit(const Value: TSimpleNonNullable<T>): T;
begin
  Check(Value);
  Result := Value.FValue;
end;

class operator TSimpleNonNullable<T>.Implicit(const Value: T): TSimpleNonNullable<T>;
begin
  Check(Value);
  Result.FValue := Value;
end;

class procedure TSimpleNonNullable<T>.Check(const Value: T);
begin
  case SizeOf(Value) of
    4:   if PInteger(@Value)^ <> 0 then Exit;
    8:   if PInt64(@Value)^   <> 0 then Exit;
    else raise ENonNullable.CreateFmt('TNonNullable<T>: Type %s is not supported.', [GetTypeName(TypeInfo(T))]);
  end;
  raise ENonNullable.CreateFmt('TNonNullable<T>: Variable %s(%p) is null.', [GetTypeName(TypeInfo(T)), @Value]);
end;

Delphi-Quellcode:

uses
  TypInfo, Variants;

type
  TNonNullable<T> = record
    class operator Implicit(const Value: TNonNullable<T>): T; inline;
    class operator Implicit(const Value: T): TNonNullable<T>; inline;
    class procedure Check(const Value: T); static;
  public type
    ENonNullable = class(Exception);
  private
    FValue: T;
  end;

{ TNonNullable<T> }

class procedure TNonNullable<T>.Check(const Value: T);
begin
  case PTypeInfo(TypeInfo(T)).Kind of
    tkPointer, tkClass, tkClassRef, tkInterface, tkProcedure, tkString, tkUString, tkDynArray, tkWString:
      if PPointer(@Value)^ <> nil then
        Exit;
    tkInteger, tkChar, tkWChar, tkEnumeration, tkSet:
      case GetTypeData(TypeInfo(T)).OrdType of
        otSByte, otUByte:
          if PByte(@Value)^ <> 0 then
            Exit;
        otSWord, otUWord:
          if PWord(@Value)^ <> 0 then
            Exit;
        otSLong, otULong:
          if PLongWord(@Value)^ <> 0 then
            Exit;
        else
          raise ENonNullable.CreateFmt('TNonNullable<T>: Type %s is not supported.', [GetTypeName(TypeInfo(T))]);
      end;
    tkInt64:
      if PInt64(@Value)^ <> 0 then
        Exit;
    tkFloat:
      case GetTypeData(TypeInfo(T)).FloatType of
        ftSingle:
          if PSingle(@Value)^ <> 0 then
            Exit;
        ftDouble:
          if PDouble(@Value)^ <> 0 then
            Exit;
        ftExtended:
          if PExtended(@Value)^ <> 0 then
            Exit;
        ftCurr:
          if PCurrency(@Value)^ <> 0 then
            Exit;
        else
          raise ENonNullable.CreateFmt('TNonNullable<T>: Type %s is not supported.', [GetTypeName(TypeInfo(T))]);
      end;
    tkMethod:
      if TMethod(Pointer(@Value)^).Code <> nil then
        Exit;
    tkVariant:
      if not VarIsNull(PVariant(@Value)^) and VarIsEmpty(PVariant(@Value)^) then
        Exit;
    else
      raise ENonNullable.CreateFmt('TNonNullable<T>: Type %s is not supported.', [GetTypeName(TypeInfo(T))]);
  end;

  raise ENonNullable.CreateFmt('TNonNullable<T>: Variable %s(%p) is null.', [GetTypeName(TypeInfo(T)), @Value]);
end;

class operator TNonNullable<T>.Implicit(const Value: TNonNullable<T>): T;
begin
  Check(Value.FValue);
  Result := Value.FValue;
end;

class operator TNonNullable<T>.Implicit(const Value: T): TNonNullable<T>;
begin
  Check(Value);
  Result.FValue := Value;
end;

[Der schöne Günther]

Parametrisierte, operator-überladene Records. Jetzt habe ich alles gesehen.

[himitsu]

Zitat von Der schöne Günther:

Parametrisierte, operator-überladene Records. Jetzt habe ich alles gesehen.

Ich hatte hier vor Jahren mal irgendwo eine Codezeile gepostet, die sah aus wie ein C++-Code, oder eher wie soein obfuscateter JavaScript-Code.
Aber im Grunde war es nur eine For-Step-Schleife, wie man sie aus QBasic kennt, welche aus anonymen Methoden bestand, vielleicht noch mit bissl Generics und alles "schön" als Einzeiler.

Delphi-Quellcode:

FOR X% = 0 TO 9 STEP 3  // 0 3 6 9 

FOR X% = 3 TO 0 STEP -1  // 3 2 1 0

Aber leider finde ich den einfach nicht mehr