Bug 632 – Typedef/enum promotions spec ambiguous - ultimate base type or lowest common denominator?

"# If one operand is a typedef and the other is the base type of that typedef, the result is the base type. # If the two operands are different typedefs but of the same base type, then the result is that base type." By "base type", does it mean the built-in type from which the typedef is ultimately derived, or the most-derived type that is a common base to both (the lowest common denominator)? In particular, it's tempting to think that, given typedef int qwert; typedef qwert yuiop; typedef qwert asdfg; that the "base type" in question is qwert, which is the immediate parent type of yuiop and adsfg, and hence that an expression involving any two of these typedefs will promote to qwert. This is similar to the common use of "base class" in OOP lingo. The better way, IMO, is to define such promotions to be to the lowest common denominator type. Consequently, any typedef (other than one of a type that's always subject to integer promotions, but that's another matter) would be closed under arithmetic operations. I imagine that implementing this principle in the compiler wouldn't be difficult. Please see http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=44821 for further commentary. But whichever method is chosen, the spec needs to be made clearer.

Issue 633 has been reduced to this one. Whatever the spec is fixed to say, it must also avoid any ambiguity in what happens when mixed enum/typedef chains are involved. This will only be an issue if the ultimate base type route is chosen - going by lowest common denominator naturally addresses this.

*** Bug 633 has been marked as a duplicate of this bug. ***