How do I defeat the gratuitous qualification of alias members?

Chad Joan chadjoan at gmail.com
Thu Apr 4 22:39:27 PDT 2013


On 04/05/2013 01:23 AM, Ali Çehreli wrote:
> On 04/04/2013 08:50 PM, Chad Joan wrote:
>
>  > There has to be a better way!
>
> You seem to be looking for the (to me) only sensible use of 'with': :)
>
> enum SANE_Status
> {
> SANE_STATUS_GOOD = 0,
> SANE_STATUS_UNSUPPORTED,
> }
>
> void foo(SANE_Status s)
> {
> final switch (s) with (SANE_Status) {
> case SANE_STATUS_GOOD: break;
> case SANE_STATUS_UNSUPPORTED: break;
> }
> }
>
> void main()
> {
> foo(SANE_Status.SANE_STATUS_GOOD);
> }
>
> If acceptable for you, I also recommend dropping the SANE_STATUS_ prefix
> from the values:
>
> enum SANE_Status
> {
> GOOD = 0,
> UNSUPPORTED,
> }
>
> void foo(SANE_Status s)
> {
> final switch (s) with (SANE_Status) {
> case GOOD: break;
> case UNSUPPORTED: break;
> }
> }
>
> void main()
> {
> foo(SANE_Status.GOOD);
> }
>
> Further, camel-casing the type and the values:
>
> enum SaneStatus
> {
> good = 0,
> unsupported,
> }
>
> void foo(SaneStatus s)
> {
> final switch (s) with (SaneStatus) {
> case good: break;
> case unsupported: break;
> }
> }
>
> void main()
> {
> foo(SaneStatus.good);
> }
>
> Ali
>

Hey Ali and Chris,

I had forgotten about 'with'.  I'll have to experiment with that.

I still want to make sure that C code with the original C enums doesn't 
require a lot of twiddling to be ported.  This means I may make a 
template to generate more D-like enums from C enums, or possibly at 
least a template to dequalify the D enums.

It's always bugged me that D enums seem to prevent the separation of two 
distinct enum features:
- Type safety.
- Forced name qualification.

Usually I find the former incredibly useful and the latter to be a 
hindrance.  It's very inconsistent with how module scoping works: module 
qualification is not required unless there is an ambiguity.  I wish 
enums worked the same way.


More information about the Digitalmars-d-learn mailing list