www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10555] New: enumerator can no longer increment beyond maximum of initializer

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10555

           Summary: enumerator can no longer increment beyond maximum of
                    initializer
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: r.sagitario gmx.de



PDT ---
I'm not sure if the new behaviour in git HEAD is desired or not, but this code
used to compile until one or two weeks ago:

enum A
{
    A0
}
enum B
{
    B0 = A.A0,
    B1
}

Now it errors out with

Error: enum test.B overflow of enum value cast(B)cast(A)0

because dmd does not want to increment A0.

More strange things:

////////////////////////
enum A
{
    A0
}
enum B
{
    B0 = A.A0,
    B1 = A.A0 + 1
}
Error: cannot implicitly convert expression (1) of type int to A

though this works

enum A
{
    A0
}
enum B
{
    B0 = A.A0 + 0,
    B1
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 06 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10555


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



08:16:59 PDT ---
Well if anything, the recent enum fixes and subsequent regressions exposed that
we have a really poor enum test-suite.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10555


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx



git bisect shows that the offending commit was
88ebe192d605bd8d4b5768e8a2500f54d73fb5fd - fix issue 3096 - EnumBaseType

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10555


Henning Pohl <henning still-hidden.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |henning still-hidden.de



PDT ---
I think this behaviour is correct:

Spec:
----
If the EnumBaseType is not explicitly set, and the first EnumMember has an
initializer, it is set to the type of that initializer. Otherwise, it defaults
to type int.

Named enum members may not have individual Types.

A named enum member can be implicitly cast to its EnumBaseType, but
EnumBaseType types cannot be implicitly cast to an enum type.
----

The behaviour before issue 3096 always used int as EnumBaseType even though
there is a first initializer.

enum A // int
{
    A0
}
enum B // A
{
    B0 = A.A0,
    B1
}

In this case the base type of B is A and A does not have a member whith a value
of 1.

enum A // int
{
    A0
}
enum B // A
{
    B0 = A.A0,
    B1 = A.A0 + 1
}

This is basically the same case as above.

enum A // int
{
    A0
}

enum B // int
{
    B0 = A.A0 + 0,
    B1
}

This works because the type of the first initializer is int. So the base type
of B becomes int and ints can be incremented easily.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 31 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10555




PDT ---
Keep in mind that you can always cast to the base type:

enum A // int
{
    A0
}

template BaseType(E)
{
    static if (is(E e == enum))
    {
        alias BaseType = e;
    }
    else
    {
        static assert("not an enum");
    }
}

enum B // int
{
    B0 = cast(BaseType!A)A.A0,
    B1
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 31 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10555


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



I agree with Henning Pohl. The behavior in 2.063/earlier was an accepts-invalid
bug, and it has been correctly fixed in git-head.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 01 2013