On Monday, June 03, 2013 04:23:00 Andrej Mitrovic wrote:
> Thoughts?

What makes this different from normal variables? This could happen with any type. You're basically trying to force people to directly initialize things in case they have bugs if they don't. If they really care about it, they can just always directly initialize it themselves. And when you have code like

Machine machine;

if(something)
{
    // do a bunch of stuff
    machine = Machine.x86;
}
else
{
    //do a bunch of other stuff
    machine = Machine.x86_64;
}

you'd be forcing people to directly initialize the machine variable even if they didn't intend to use the value. And directly initializing the variable generally indicates that you're giving it a value that you intend to use rather than letting it be the default until you actually _do_ given it a valid value.

This is like how Java forces you to directly initialize things when it doesn't think that you've initialized them elsewhere. D did _not_ take that route. It when with have an init value for every type and initializing with that. The feature that you're suggesting would not be in line with that design decision.

- Jonathan M Davis

On 6/3/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Machine machine;
>
> if(something)
> {
>     // do a bunch of stuff
>     machine = Machine.x86;
> }
> else
> {
>     //do a bunch of other stuff
>     machine = Machine.x86_64;
> }
>
> you'd be forcing people to directly initialize the machine variable even if they didn't intend to use the value.

I'd hope in that case the compiler would be smart enough to realize the variable is indeed initialized before use, and would avoid the compiler error.

On 6/3/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> This is like how Java forces you to directly initialize things when it doesn't think that you've initialized them elsewhere. D did _not_ take that route. It when with have an init value for every type and initializing with that.

Yes, but we do have float.init which is NaN. We don't have the equivalent for enums.

On Monday, June 03, 2013 04:57:28 Andrej Mitrovic wrote:
> On 6/3/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > This is like how Java forces you to directly initialize things when it doesn't think that you've initialized them elsewhere. D did _not_ take that route. It when with have an init value for every type and initializing with that.
> Yes, but we do have float.init which is NaN. We don't have the equivalent for enums.

The situation is exactly the same with ints. We don't have an actual error value. 0 is the best we have. If you want something that's effectively invalid, then creating an "invalid" value as the first enum value as you already suggested would be the correct thing to do. Whereas what you're suggesting in this thread would be the equivalent of making

int i;

illegal, only your suggestion is specifically for enums.

If programmers don't want to risk using the default value for one reason or another, then they can choose to directly initialize it. I see no reason to force that upon them, and it goes against how the rest of the language is designed. Your suggestion for an "invalid" value for the first enum value was a good one and should be enough IMHO if you don't want the default enum value to be valid.

- Jonathan M Davis

On Sun, 02 Jun 2013 20:03 -0700, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Your suggestion for an "invalid" value for the first enum value
> was a good one and should be enough IMHO if you don't want the default enum value
> to be valid.

Actually, I just figured out that we already have support for what I've asked for:

enum_mod.d:
-----
module enum_mod;

private enum MachineEnum
{
    X86,
    X86_64,
}

struct InitEnum(E) if (is(E == enum))
{
    @disable this();
    this(E e) { value = e; }

    E value;
    alias value this;
}

alias Machine = InitEnum!MachineEnum;  // "fake" enum
-----

test.d:
-----
import enum_mod;

void main()
{
    // Machine machine;  // compile-time error
    Machine machine = Machine.X86;  // ok
}
-----

How damn cool is that?

On 6/3/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Actually, I just figured out that we already have support for what I've asked for.

Well apparently switch/final switch doesn't work with subtyping, I'll try to file this as a bug.