Kommen wir nun zu den concepts. Wie anfangs erwähnt, las ich das Paper [1].
Ich erlaube mir hier ein paar Ausschnitte davon zu kommentieren, um meine Motivation zu begründen.
A concept has semantics; it means something; it is not just a
set of unrelated operations and types. Without an idea of what operations mean and how they relate to each other we cannot write generic code that works for all appropriate types.
Ein Konzept bedeutet also irgendetwas. Wenn man sich hinsetzt und irgendetwas programmiert, hat man irgendetwas im Kopf, was es bedeuten soll. Aber diese Bedeutung können wir nur schwer in Code formulieren. Das liegt erfahrungsgemäß nicht nur an der Sprache und ihre Mittel, hauptsächlich ist es der Programmierer, der nicht weiß was er will.
So wird viel ausprobiert und viel Code umgeschrieben. Und dabei ein Haufen Bugs eingebaut, die vermeidbar gewesen wären, hätte man sich nur mal kurz überlegt, was man überhaupt will.
It follows that a guarantee that all types accepted by concept checking
will work correctly is impossible: they may have exactly the syntactic properties required, but have the wrong semantics. This is nothing new: Similarly, a function taking a double can
interpret it differently from what the caller expects. Consider set_speed(4.5). What does this mean? Is 4.5 supposed to be in m/s or maybe miles/hour? Is 4.5 an absolute value, a delta to the current speed, or possibly a factor of change?
Genau hier will ich ansetzen und widersprechen.
Der Programmierer der Funktion set_speed hat in seinem Kopf gewusst, was die Funktion machen soll, und was der Funktionsparameter bedeutet. Das muss so sein, sonst hätte er sie nicht programmieren können. Er hat diese Dinge aber nicht in Code formuliert. Wenn zum Beispiel die Funktion set_speed als Argument kein double entgegen nimmt, sondern ein Type namens Speed, welcher intern auf den Physikalischen Einheiten Meter pro Sekunde definiert ist, dann ist es nicht möglich aus versehen eine Geschwindigkeit in miles/hours zu übergeben, ohne dass der Compiler aktiv wird.
Selbes gilt für eine Geschwindigkeitsänderung welche z.B. durch den Typ DeltaSpeed ausgedrückt werden könnte, oder eine Änderung durch Skalierung.
Genau darum geht es. Um die Bedeutung von Variablen. Um die Bedeutung des Variablentypes, der mittels concepts zur Compilezeit überprüft werden kann.
I suspect that perfect checking for all code will forever elude us;
Hier bin ich vom Gegenteil überzeugt. Sobald alle Informationen ohne Fehler für den Compiler in auswertbarer Form vorliegen, muss der Compiler immer ein Fehler liefern, sobald man Schwachsinn programmiert hat.
Es macht in keinem Universum Sinn, Geschwindigkeit und Abstand zu addieren. Hier wird der Compiler sofort aktiv.
Auch Algorithmen müssen vom Compiler überprüfbar sein. Wenn alle Ein- und Ausgabedaten durch Prädikate beschrieben werden, muss der Compiler Fehler im Algorithmus finden.
Wenn aber jemand den Abstand Erde-Sonne in Millimeter berechnen will, ist das natürlich kein Compilezeitfehler.
Im nächsten Teil gibt es wieder C++ Code.
[1] Concepts: The Future of Generic Programming or How to design good concepts and use them well - Bjarne Stroustrup