import std.stdio;

enum Intention
{
   EVIL,
   NEUTRAL,
   GOOD,
   SAINTLY
}

void foo(Intention rth)
{
   if (rth == EVIL)
      writeln("Road to hell");
}


void main()
{
   foo(EVIL);
}


Why does the compiler complain in both places about EVIL. Can it not work out which EVIL I mean? There's only one choice.

On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
> import std.stdio;
>
> enum Intention
> {
>    EVIL,
>    NEUTRAL,
>    GOOD,
>    SAINTLY
> }
>
> void foo(Intention rth)
> {
>    if (rth == EVIL)
>       writeln("Road to hell");
> }
>
>
> void main()
> {
>    foo(EVIL);
> }
>
>
> Why does the compiler complain in both places about EVIL. Can it not work out which EVIL I mean? There's only one choice.

That should be:

if( rth == Intention.EVIL ) and
foo( Intention.EVIL );

On Thursday, 21 November 2013 at 07:28:14 UTC, Craig Dillabaugh
wrote:
> On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
clip
>>
>>
>> Why does the compiler complain in both places about EVIL. Can it not work out which EVIL I mean? There's only one choice.
>
> That should be:
>
> if( rth == Intention.EVIL ) and
> foo( Intention.EVIL );

I should also mention, this post likely better belongs in:

digitalmars.D.learn

That is the best place for questions about how the language
works. This forum is more a place for the D Pros to fight it out
over what features should/shouldn't be in the langauge.

On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
> import std.stdio;
>
> enum Intention
> {
>    EVIL,
>    NEUTRAL,
>    GOOD,
>    SAINTLY
> }
>
> void foo(Intention rth)
> {
>    if (rth == EVIL)
>       writeln("Road to hell");
> }
>
>
> void main()
> {
>    foo(EVIL);
> }
>
>
> Why does the compiler complain in both places about EVIL. Can it not work out which EVIL I mean? There's only one choice.

I don't think it would be a good idea to let a compiler decide which symbol I mean :). So you must use Intention.EVIL instead of just EVIL. Or you can do some trick like this:

enum Intention : int {_}
enum : Intention
{
    EVIL = cast(Intention)0,
    NEUTRAL = cast(Intention)1,
    GOOD = cast(Intention)2,
    SAINTLY = cast(Intention)3,
}

void foo(Intention rth)
{
    if (rth == EVIL)
        writeln("Road to hell");
}

void main()
{
    foo(EVIL);
}

or use aliases:

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

alias EVIL = Intention.EVIL;
alias NEUTRAL = Intention.NEUTRAL;
alias GOOD = Intention.GOOD;
alias SAINTLY = Intention.SAINTLY;

void foo(Intention rth)
{
    if (rth == EVIL)
        writeln("Road to hell");
}

void main()
{
    foo(EVIL);
}

On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh wrote:
> I should also mention, this post likely better belongs in:
>
> digitalmars.D.learn

I don't entirely think so. I think the OP is arguing that D should be able to identify symbol as specific enum's field when used:
  - in place of function argument when the fn parameters is of enum type
  - and when comparing for equality with variable of enum type.

ie. the lookup of the symbol should be first inside the enum, and the continue normally.

There was plan long long time ago to implement it, but I don't remember for which reason it was not.

In order to consider this again for implementation I think proper DIP should be written where complete semantics of this should be described. For one I don't know how it should be have if you would have variable of the same name as enum field i.e:

enum State { on, off }
auto State s;
auto on = 1;
if (on == on) ?

And I think it would be especially confusing when enum which is function parameters has the same field name as local variable on call site:

void change (State s) {}
void main () { State on = State.off, change (on) }

On Thursday, 21 November 2013 at 08:05:03 UTC, Michal Minich
wrote:
> On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh wrote:
>> I should also mention, this post likely better belongs in:
>>
>> digitalmars.D.learn
>
> I don't entirely think so. I think the OP is arguing that D should be able to identify symbol as specific enum's field when used:
>   - in place of function argument when the fn parameters is of enum type
>   - and when comparing for equality with variable of enum type.

Yes, perhaps that was his intention (no pun intended). First few
times I used enums in D I was caught because I expected the
behavior he is suggesting here would work.

On Thursday, 21 November 2013 at 08:05:03 UTC, Michal Minich wrote:
> On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh wrote:
>> I should also mention, this post likely better belongs in:
>>
>> digitalmars.D.learn
>
> I don't entirely think so. I think the OP is arguing that D should be able to identify symbol as specific enum's field when used:
>   - in place of function argument when the fn parameters is of enum type
>   - and when comparing for equality with variable of enum type.
>
> ie. the lookup of the symbol should be first inside the enum, and the continue normally.
>
> There was plan long long time ago to implement it, but I don't remember for which reason it was not.
>
> In order to consider this again for implementation I think proper DIP should be written where complete semantics of this should be described. For one I don't know how it should be have if you would have variable of the same name as enum field i.e:
>
> enum State { on, off }
> auto State s;
> auto on = 1;
> if (on == on) ?
>
> And I think it would be especially confusing when enum which is function parameters has the same field name as local variable on call site:
>
> void change (State s) {}
> void main () { State on = State.off, change (on) }

Michal,

Well thank you for a sane reply! I've been with D since about 2006, and I prefer to not make a complete fool of myself.

I have to admit that the question was asked in anger. I was working on some old code, and saw this large bare enum, so I gave it a qualifier. It then took me about six hours to stubbornly go through the rest of the code to add the qualifier - aargh!

Yes, I agree that the circumstances under which the inference could be made may be limited, but in a function where a single argument is an enum name it's really surprising that it is not implemented.

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?

On Thursday, 21 November 2013 at 08:37:32 UTC, Craig Dillabaugh wrote:
> Yes, perhaps that was his intention (no pun intended). First few
> times I used enums in D I was caught because I expected the
> behavior he is suggesting here would work.

Pun was intended ;=)

On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
> import std.stdio;
>
> enum Intention
> {
>    EVIL,
>    NEUTRAL,
>    GOOD,
>    SAINTLY
> }
>
> void foo(Intention rth)
> {
>    if (rth == EVIL)
>       writeln("Road to hell");
> }
>
>
> void main()
> {
>    foo(EVIL);
> }
>
>
> Why does the compiler complain in both places about EVIL. Can it not work out which EVIL I mean? There's only one choice.

Because of the follwoing:

import foo.bar;

enum Intention
{
  EVIL,
  NEUTRAL,
  GOOD,
  SAINTLY
}

void foo(Intention rth)
{
...
}

void main()
{
  // imagine that this works
  foo(EVIL);
}

module foo.bar;

// someone else adds this later
enum OtherIntention
{
  EVIL,
  NEUTRAL,
  GOOD,
  SAINTLY
}

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

On Thursday, 21 November 2013 at 17:19:18 UTC, inout wrote:
> On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
>> import std.stdio;
>>
>> enum Intention
>> {
>>   EVIL,
>>   NEUTRAL,
>>   GOOD,
>>   SAINTLY
>> }
>>
>> void foo(Intention rth)
>> {
>>   if (rth == EVIL)
>>      writeln("Road to hell");
>> }
>>
>>
>> void main()
>> {
>>   foo(EVIL);
>> }
>>
>>
>> Why does the compiler complain in both places about EVIL. Can it not work out which EVIL I mean? There's only one choice.
>
> Because of the follwoing:
>
> import foo.bar;
>
> enum Intention
> {
>   EVIL,
>   NEUTRAL,
>   GOOD,
>   SAINTLY
> }
>
> void foo(Intention rth)
> {
> ...
> }
>
> void main()
> {
>   // imagine that this works
>   foo(EVIL);
> }
>
> module foo.bar;
>
> // someone else adds this later
> enum OtherIntention
> {
>   EVIL,
>   NEUTRAL,
>   GOOD,
>   SAINTLY
> }
>
> 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?