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.
