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.