[Issue 24833] New: enums with a base type with a copy / postblite ctor, opAssign, or dtor should either use them or be disallowed

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=24833

          Issue ID: 24833
           Summary: enums with a base type with a copy / postblite ctor,
                    opAssign, or dtor should either use them or be
                    disallowed
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P1
         Component: dmd
          Assignee: nobody at puremagic.com
          Reporter: issues.dlang at jmdavisProg.com

At present, enums with a base type that has a copy constructor, postblit
constructor, overloaded assignment operator, and/or destructor completely
ignore those functions. E.G.

---
void main()
{
    import std.traits;

    static struct S
    {
        int i;

        void opAssign()(auto ref S rhs)
        {
            this.i = rhs.i;
        }

        this(this)
        {
        }

        ~this()
        {
        }
    }

    enum E : S
    {
        a = S(42)
    }

    static assert(hasElaborateAssign!S);
    static assert(hasElaborateCopyConstructor!S);
    static assert(hasElaborateDestructor!S);

    // These pass but should not
    static assert(!hasElaborateAssign!E);
    static assert(!hasElaborateCopyConstructor!E);
    static assert(!hasElaborateDestructor!E);
}
---

This is fundamentally broken, because any type that has any of those functions
clearly was designed to have them and almost certainly will not work correctly
if they are not called. I do not really see any real argument for why the
current behavior is reasonable, and I expect that it's an oversight in the enum
implementation, and it hasn't come up more simply because it's not very common
in D to declare enums which are structs.

The spec does currently mention that they are not called -
https://dlang.org/spec/enum.html#enum_copying_and_assignment. However, as I
understand it, that's simply because Paul Backus decided to document the
current behavior rather than it being purposefully decided by someone like
Walter.

Now, there are obviously some complications with these functions and enum types
(particularly the assignment operator) given that they're written to deal with
the base type, not the enum type, requiring conversions. So, I don't know how
reasonable it is to support them with enums. However, if it's not reasonable to
support them, then IMHO, such structs should simply be disallowed as the base
type of enums, since they cannot function properly if those functions are not
called properly like they would be with the base type.

A related issue is: https://issues.dlang.org/show_bug.cgi?id=24225

--