Irgendwo muss dann aber beim break der Scope definiert sein, der damit verlassen wird.
Ja gut, wie gesagt, bei C gibt es das gleiche Problem, dass ein break nicht für eine außenliegende Schleife zuständig ist.
Oder besser gesagt, dass break wäre in diesem Fall IMMER für das case .. of zuständig, und nicht für die außenliegende Schleife.
Ok, zumindest könnte man sagen, dass dies ein halbwegs plausibler Grund gegen break im case wäre.
Man könnte aber auch so argumentieren:
Delphi-Quellcode:
case LMyVariable of
TMyVariable.One: X := 1; //<= HIER ist de facto ein "BREAK", Ende des case statements
TMyVariable.ThreeBlue: begin
Mache1;
if not MyCondition then
begin
break; //<= HIER soll es kein "BREAK", Ende des case statements geben
end;
Mache2;
end; //<= HIER ist de facto ein "BREAK", Ende des case statements
end;
Man könnte vielleicht mal einen Feature-Request stellen ...
! Ich hatte explizit im Anfage gesagt, dass ich keinen Feature-Request möchte.
Ich möchte nur die Gründe kennen, die dagegen sprechen.
Da hätte ich an Pfade oder Sprungoptimierungen gedacht, aber es scheint nur philosophische Gründe dagegen zu sprechen.
Eingeschlossen, wie oben, dass ein break dann das break einer außenliegenden Schleife wegnehmen würde.
Ok, ok, belassen wir es dabei.
Ich brauche keine alternativen Vorschläge dazu, ich hatte ja schon erklärt, dass ich gerne Guards einsetze,
statt tiefverschachtelter, unübersichtlicher if-then-else.
Wahrscheinlich macht es dann sowieso Sinn statt "begin end;" im case zu haben, besser eine spezifische Case-Funktion aufzurufen.