Re: enum pointers or class references limitation

[Timon Gehr via Digitalmars-d]

On 30.08.2017 11:36, Dmitry Olshansky wrote:
The subj is not (any longer) supported by compiler. In fact it used to 
produce wrong code sometimes and now it just plainly rejects it.

It's freaking inconvenient because I can't deploy new compile-time 
std.regex w/o it.

The example:

enum ctr = ctRegex!"blah";

after my changes must be:

static immutable ctr = ctRegex!"blah";

Howeever I divised a trick to get equivalent functionality as follows:

template ctRegexImpl(alias pattern, string flags=[])
{
    static immutable staticRe = ...;
    struct Wrapper
    {
       @property auto getRe(){ return staticRe; }
       alias getRe this;
    }
    enum wrapper = Wrapper();
}

public enum ctRegex(alias pattern, alias flags=[]) = 
ctRegexImpl!(pattern, flags).wrapper;

Now ctRegex returns a neat forwarding struct that bypasses the strange 
limitation. The question remains though - why can't compiler do it 
automatically?


I think the underlying reason why it does not work is that dynamic array 
manifest constants are messed up. I.e. class reference `enum`s are 
disallowed in order to avoid having to make a decision for either 
inconsistent or insane semantics.