www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Enums, typedefs and lowest common denominators

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
http://www.digitalmars.com/d/type.html

typedef, the result is the base type.

then the result is that base type."

Something's puzzling here.  I first noticed a problem when the SDWF 
example program MDI Edit stopped compiling.  For the record, the error is:
----------
mdiedit.d(284): function smjg.libs.sdwf.windowbase.WindowBase.style () 
does not match parameter types (uint)
mdiedit.d(284): Error: cannot implicitly convert expression 
(((cast(WindowBase)(this.editBox)).style)() | cast(ES)cast(WS)256u) of 
type uint to WS
----------

This appears to be due to promotion rules that have been in place for a 
while, but the problem with this code has only just manifested in the 
light of the fix to bug 349.

http://d.puremagic.com/issues/show_bug.cgi?id=349

Anyway, back to the point.  It would appear that by "base type" the spec 
means the built-in (or class or struct or union) type from which the 
typedef is ultimately derived.

This spec doesn't mention anything about enums, but the compiler seems 
to be treating enums and typedefs as a single entity in this respect. 
For example:
----------
import std.stdio;

typedef uint EnumBase;

enum Enum1 : EnumBase { Value1, Value2 }
enum Enum2 : EnumBase { Value3, Value4 }

void test(EnumBase e) {
     writefln("EnumBase: %d", e);
}

void test(uint e) {
     writefln("uint: %d", e);
}

void main() {
     test(Enum1.Value1 | Enum2.Value4);
}
----------

shows that the enum values are promoted to uint, which is the ultimate 
base type of both enums, as passing through both enums and typedefs.

When I suggested OUAT how typedef arithmetic should work, I intended 
typedefs with a common base type to promote to the lowest common 
denominator, i.e. the most-derived typedef that is a common base to 
both.  It would make sense to apply this logic also to enums, and even 
to chains of typedefs and enums.

But the spec certainly has holes here.  Firstly, it ought to clarify 
what is meant by "base type"; secondly, it needs to mention what happens 
to enums in the same circumstance.

Under the lowest common denominator principle, my code would compile 
without trouble.  But for as long as they are always promoted to the 
_ultimate_ base type if at all, it's hard to make these hierarchical 
enums work properly and keep SDWF user-friendly to this degree.  It's 
nice if people can still use

     editBox.style = editBox.style | ES.NOHIDESEL;

rather than

     editBox.style = cast(WS) (editBox.style | ES.NOHIDESEL);


Comments?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Nov 27 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Stewart Gordon wrote:

 
 Something's puzzling here.  I first noticed a problem when the SDWF 
 example program MDI Edit stopped compiling.  For the record, the error is:
 ----------
 mdiedit.d(284): function smjg.libs.sdwf.windowbase.WindowBase.style () 
 does not match parameter types (uint)
 mdiedit.d(284): Error: cannot implicitly convert expression 
 (((cast(WindowBase)(this.editBox)).style)() | cast(ES)cast(WS)256u) of 
 type uint to WS
 ----------
 


Take a look at http://d.puremagic.com/issues/show_bug.cgi?id=605

In the sample code, if the definition to struct sockaddr_in is commented out,
all seems to work fine 
w/o a cast.

Hopefully that will localize the bug enough for Walter to determine the cause.
Nov 27 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Stewart Gordon wrote:

 http://www.digitalmars.com/d/type.html

 typedef, the result is the base type.

 then the result is that base type."


...

 This appears to be due to promotion rules that have been in place for a 
 while, but the problem with this code has only just manifested in the 
 light of the fix to bug 349.
 
 http://d.puremagic.com/issues/show_bug.cgi?id=349


This appears related to the bug report I just submitted:

http://d.puremagic.com/issues/show_bug.cgi?id=580


 Anyway, back to the point.  It would appear that by "base type" the spec 
 means the built-in (or class or struct or union) type from which the 
 typedef is ultimately derived.
 
 This spec doesn't mention anything about enums, but the compiler seems 
 to be treating enums and typedefs as a single entity in this respect.


I think this changed at some point.  The code in which I found the bug 
reported in 580 worked fine until a few months ago.  I made a temporary 
change to work around the problem and forgot to report it, and the 
behavior persists in 175.


Sean
Nov 27 2006