Interpretation of assertions with struct declaration

[f37yu]

Currently, assertion parameters placed on a struct declaration is interpreted as assertion on special operators (ctor/dtor/assign), which means they might be elided or forcefully bypassed.

Some test results:

forall(T | { void foo(T); })
struct S {
  T t;
};

S(int) s1; // error: cannot satisfy assertion for ?{}
S(int) s2 = {0}; // error: cannot satisfy assertion for ?{}
S(int) s3 @= {0}; // ok ...?

forall(T | { void foo(T); })
struct U {
  T * t;
};

U(int) u1; // ok ...?

A problem comes up, under the "business as usual" interpretation, that the assertions apply to the autogen functions. The problem is that it is possible to declare custom constructors or destructors with fewer assertions than the autogen ones; by the specialization cost element, the custom ones are less specialized than the autogen ones, so the autogen ones are still preferred.

forall(T)
trait is_happy {
    void sayHi(T);
};

forall(T           | is_happy(T) )
struct thing { T item; };

forall(T
#ifdef REMEMBER_ASSN
                          | is_happy(T)
#endif
                                        )
void ^?{}( thing(T) & ) {
    printf("custom dtor called\n");
}

void sayHi(float) {}

int main() {
    thing(float) x;
}

Actual, plain compile: Compile succeeds; run produces no output, showing the custom destructor was not called.

Expected, plain compile: Error, you are obviously trying to declare a destructor, but because your declaration is missing an assertion, it will never be chosen.

Actual and expected -DREMEMBER_ASSN: Compile succeeds, custom destructor is called. This is the state that the expected error will help the programmer reach.

[ajbeach]

I was in the area and so updated the trait format and otype keyword.