Currently, the double underscore prefix is reserved, but I've been wondering if there are any other identifier resrictions for D.  C, for example, also reserves underscore followed by a capital letter for exclusive use, and all other underscore-prefixed identifiers for use at file scope.  Since it will be quite common for D to link to C libraries, do these rules hold for D as well?  And what about the D library itself?  I've noticed that Phobos uses both leading underscore conventions in different circumstances: the underscore capital identifiers seem to typically represent C library code, while underscore lowercase identifiers are more common for D-level externs.  The safest prefix for D library code is probably some subset of the underscore lowercase range (such as the "_d_" prefix used for callbacks) but nothing entirely eliminates the possibility of a conflict.  I think this naming issue is only a concern for extern(C) functions so there should not be a real risk of collisions anyway, but I figured it was worth asking.  Should normal folks or library implementors follow any naming convention?


Sean

In article <djcbnd$cja$1@digitaldaemon.com>, Sean Kelly says...
>
>Currently, the double underscore prefix is reserved, but I've been wondering if there are any other identifier resrictions for D.  C, for example, also reserves underscore followed by a capital letter for exclusive use, and all other underscore-prefixed identifiers for use at file scope.  Since it will be quite common for D to link to C libraries, do these rules hold for D as well?  And what about the D library itself?  I've noticed that Phobos uses both leading underscore conventions in different circumstances: the underscore capital identifiers seem to typically represent C library code, while underscore lowercase identifiers are more common for D-level externs.  The safest prefix for D library code is probably some subset of the underscore lowercase range (such as the "_d_" prefix used for callbacks) but nothing entirely eliminates the possibility of a conflict.  I think this naming issue is only a concern for extern(C) functions so there should not be a real risk of collisions anyway, but I figured it was worth asking.  Should normal folks or library implementors follow any naming convention?

I've considered this a bit and I think the C restrictions must be preserved in D, simply because D programs can link to C libraries and include imported C header files.  Since D has visibility specifiers (protected, private), the file-scope prefix isn't needed by the D library, but a way to use externs is. Therefore, I propose that the "_D_" subset of the underscore uppercase namespace be reserved for D library use.  This will allow extern(C) functions to be declared for library use without any risk of collisions with user or (hopefully) C library code.  How does this sound?


Sean