I have a feature request: "Named enum scope inference"

Alex Rønne Petersen alex at lycus.org
Fri Sep 28 19:01:46 PDT 2012


On 29-09-2012 03:55, Tommi wrote:
> I have a feature request: "Named enum scope inference"
>
> The idea is, that whenever a named enum value is expected, you don't
> need to explicitly specify the scope of the enum value. This would
> reduce redundancy in typing, just like automatic type inference does.
>
> Examples:
> ---------
>
> enum MyDirection { forward, reverse }
>
> struct MyIterator(MyDirection dir)
> {
>      ...
> }
>
> int forward = 42; // Doesn't interfere with the next line...
> auto itr = MyIterator!forward(); // Infers MyDirection.forward
>
> ----------------------------------------------------------------
>
> enum MyLockType { read, read_write }
>
> struct MyScopedLock
> {
>      this(MyMutex mutex, MyLockType lockType)
>      {
>          ...
>      }
> }
>
> shared MyMutex g_mutex;
> ...
> auto scopedLock = MyScopedLock(g_mutex, read_write);
> // Infered MyLockType.read_write
>
> // Side note: Compare the above to having a boolean flag...
> auto scopedLock = MyInferiorScopedLock(g_mutex, true);
> // ... and you have to read the docs to know what 'true' means
>
> ----------------------------------------------------------------
>
> enum MyFruit { apple, orange, banana }
>
> MyFruit fruit;
>
> switch (fruit)
> {
>      case apple:  break; // Case expressions know what type to
>      case orange: break; // expect based on the switch expression
>      case banana: break;
> }
>
>
>

The first issue with this proposal that comes to mind is this:

enum Foo { bar }

void func(Foo f)
{
     // ...
}

// ...

Foo bar = Foo.bar;
func(bar); // ?

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org


More information about the Digitalmars-d mailing list