On 11/21/13 8:48 AM, Steve Teale wrote:
> Could 'with' be extended to cover enum names do you think? Also a
> supplementary question - does auto lock out some things like this, are
> there other examples?

Guess it could. One other thing we could do is to make enum namespaces behave like imports.

Andrei

On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei Alexandrescu wrote:
> On 11/21/13 8:48 AM, Steve Teale wrote:
>> Could 'with' be extended to cover enum names do you think? Also a
>> supplementary question - does auto lock out some things like this, are
>> there other examples?
>
> Guess it could. One other thing we could do is to make enum namespaces behave like imports.
>
> Andrei

+1.  I love this idea.  Verbosity only when necessary.

On Thursday, 21 November 2013 at 16:48:59 UTC, Steve Teale wrote:
> Could 'with' be extended to cover enum names do you think? Also a supplementary question - does auto lock out some things like this, are there other examples?

Is this what you mean?

enum Intention
{
	EVIL,
	NEUTRAL,
	GOOD,
	SAINTLY,
}

void main()
{
	with (Intention)
	{
		assert(EVIL == 0);
		assert(NEUTRAL == 1);
		assert(GOOD == 2);
		assert(SAINTLY == 3);
	}
}

>>
>> BOOM! Code no longer compiles.
>>
>> As a rule, the code that compiles and works should preserve its behavior when new code is added, so this is prohibited.
>>
>> Also please post to D.learn
>
> forgot to add:
>
> void foo(OtherIntention rth) { ... }
>
> Which of the two is being called by main?

I thought that compilers were supposed to help you if you did ambiguous things. An interesting example is:

int bar(int n)
{
   return n+1;
}

int bar(int n)
{
   return n+2;
}

void main()
{
   int v = 22;
   int n = bar(22);
}

On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei Alexandrescu wrote:
> On 11/21/13 8:48 AM, Steve Teale wrote:
>> Could 'with' be extended to cover enum names do you think? Also a
>> supplementary question - does auto lock out some things like this, are
>> there other examples?
>
> Guess it could. One other thing we could do is to make enum namespaces behave like imports.
>
> Andrei

I'd love to understand "make enum namespaces behave like imports", but I should probably ask that on D Learn ;=)

>
> That should be:
>
> if( rth == Intention.EVIL ) and
> foo( Intention.EVIL );

Phobos is less picky than the compiler. Try this:

import std.stdio;

enum Intention
{
   EVIL,
   NEUTRAL,
   GOOD,
   SAINTLY
}

void foo(Intention rth)
{
   if (rth == Intention.EVIL)
      writefln("The road to hell is paved with %s and %d", rth, rth);
}


void main()
{
   foo(Intention.EVIL);
}

On Thursday, 21 November 2013 at 18:44:39 UTC, Steve Teale wrote:
> On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei Alexandrescu wrote:
>> On 11/21/13 8:48 AM, Steve Teale wrote:
>>> Could 'with' be extended to cover enum names do you think? Also a
>>> supplementary question - does auto lock out some things like this, are
>>> there other examples?
>>
>> Guess it could. One other thing we could do is to make enum namespaces behave like imports.
>>
>> Andrei
>
> I'd love to understand "make enum namespaces behave like imports", but I should probably ask that on D Learn ;=)

When you import from a module, you only need to specify the module name if there is ambiguity. So for example:

//----
import std.array;

void main()
{
    split("hello"); //OK!
}
//----
import std.array;
import std.algorithm;

void main()
{
    split("hello"); //Wait... did you want std.algorithm.split, or std.array.split?
    std.array.split("hello"); //OK! That's clearer now.
}
//----

What Andrei is saying is that an enum *could* work the same way:

enum RedBlack //For red black trees
{
    Red,
    Black,
}
enum BlackWhite //For Checker boards
{
    Black,
    White,
}

void main()
{
    writeln(Red); //OK! No problem!
    writeln(Black); //I'm sorry... that's ambiguous :/
    writeln(RedBlack.Black); //OK! That's clearer now!
}

Whether or not it *should*, I don't know. "Why not?" I like to say :)

On 11/21/2013 02:20 PM, monarch_dodra wrote:
>
> When you import from a module, you only need to specify the module name
> if there is ambiguity. So for example:
>
> //----
> import std.array;
>
> void main()
> {
>      split("hello"); //OK!
> }
> //----
> import std.array;
> import std.algorithm;
>
> void main()
> {
>      split("hello"); //Wait... did you want std.algorithm.split, or
> std.array.split?
>      std.array.split("hello"); //OK! That's clearer now.
> }
> //----
>
> What Andrei is saying is that an enum *could* work the same way:
>
> enum RedBlack //For red black trees
> {
>      Red,
>      Black,
> }
> enum BlackWhite //For Checker boards
> {
>      Black,
>      White,
> }
>
> void main()
> {
>      writeln(Red); //OK! No problem!
>      writeln(Black); //I'm sorry... that's ambiguous :/
>      writeln(RedBlack.Black); //OK! That's clearer now!
> }
>
> Whether or not it *should*, I don't know. "Why not?" I like to say :)

If both these enums are coming from a module and I also have a RedBlack enum in my main program that has Black in it, then I guess it would be

modulename.RedBlack.Black

to call the one from the module.

Does it make sense?
I should be really in D.learn but asked that here in context ;)

On 11/21/2013 01:36 PM, Steve Teale wrote:
> I thought that compilers were supposed to help you if you did ambiguous
> things. An interesting example is:
>
> int bar(int n)
> {
>     return n+1;
> }
>
> int bar(int n)
> {
>     return n+2;
> }
>
> void main()
> {
>     int v = 22;
>     int n = bar(22);
> }


Compiler helps here by throwing an error.
Those are two duplicate functions with same exact arguments.

On Friday, 22 November 2013 at 00:50:25 UTC, John J wrote:
> On 11/21/2013 02:20 PM, monarch_dodra wrote:
>>
>> When you import from a module, you only need to specify the module name
>> if there is ambiguity. So for example:
>>
>> //----
>> import std.array;
>>
>> void main()
>> {
>>     split("hello"); //OK!
>> }
>> //----
>> import std.array;
>> import std.algorithm;
>>
>> void main()
>> {
>>     split("hello"); //Wait... did you want std.algorithm.split, or
>> std.array.split?
>>     std.array.split("hello"); //OK! That's clearer now.
>> }
>> //----
>>
>> What Andrei is saying is that an enum *could* work the same way:
>>
>> enum RedBlack //For red black trees
>> {
>>     Red,
>>     Black,
>> }
>> enum BlackWhite //For Checker boards
>> {
>>     Black,
>>     White,
>> }
>>
>> void main()
>> {
>>     writeln(Red); //OK! No problem!
>>     writeln(Black); //I'm sorry... that's ambiguous :/
>>     writeln(RedBlack.Black); //OK! That's clearer now!
>> }
>>
>> Whether or not it *should*, I don't know. "Why not?" I like to say :)
>
> If both these enums are coming from a module and I also have a RedBlack enum in my main program that has Black in it, then I guess it would be
>
> modulename.RedBlack.Black
>
> to call the one from the module.
>
> Does it make sense?
> I should be really in D.learn but asked that here in context ;)

If the enum's name is RedBlack, and you want the Black value, than yes., you'd need to "double disambiguate".

If you wanted Red though, then:
modulename.Red
Should be enough to un-ambiguously refer to the correct enum value.