Heiko L. schrieb:
> Was spricht gegen das naive "constexpr operator==, wenn der nicht
> richtig funktioniert ist es halt UB"?
Gott bewahre: nicht noch mehr davon!
Ich bin kein Compilerbauer und ich habe großen Respekt vor diesen Mädels
und Jungs. Deswegen ist meine Antwort hier nur laienhaft:
1) Das bisherige Modell der getrennten Übersetzungseinheiten soll
beibehalten werden
2) Aus 1) folgt, dass der Linker template-ids vergleichen können muss.
3) Für 2) wird bei NTTP deren Bit-Repräsentation als Wert in die
template-id verwurschtelt (mangled)
4) Die Bit-Repräsentation eines class-type NTTP ist Summe der
Bit-Repräsentationen der member.
5) Das ist identisch mit einer Gleichheitsdefinition von class-type
NTTP, die auf allen ihren membern basiert.
6) Ein op== müsste dazu auf jeden Fall dazu konsistent implementiert
werden.
7) Man kann 6) für user-defined op= nicht sicher stellen
8) Daher erzwingt man 6) durch den Verzicht auf Klasseninvarianten durch
all-public member, d.h. der beobachtbare Zustand eines Typs sind alle(!)
member, daher ist die Gleichheit zweiter Objekte durch einen
elementweisen Vergleich gegeben.
Bottom-line: man bräuchte eine konsistente Abbildung des Objektzustandes
(Werte) in eine template-id. Dazu ist für C++23 ein "operator template"
vorgeschlagen. Wie man für den dann allerdings die Konsistenz mit op==
bzw. op<=> sicherstellen will, ist mir noch nicht klar. Man läuft dann
in dasselbe Problem wie bei Java mit equals() und hashCode().
Das ist eine "Lösung", die eben bestimmte Typen ausschließt, aber
ansonsten in das bisherige Modell passt, ohne neue Schwierigkeiten
einzubauen.