enum pointers or class references limitation

[Timon Gehr via Digitalmars-d]

On 02.09.2017 01:13, Q. Schroll wrote:
> On Friday, 1 September 2017 at 21:08:20 UTC, Ali Çehreli wrote:
>> [snip]
>> > assert(!([1,2,3] is [1,2,3]));
>> >
>> > Which is exactly what enum expands to and totally expected.
>> Where is the
>> > surprise?
> 
> This is not a surprise. Array literals are not identical.
> 
>> In the surprising case foo is a symbol, seemingly of a variable. 
>> Failing the 'is' test is surprising in that case. I've just remembered 
>> that the actual surprising case is the following explicit check:
>>
>>     assert(!(foo.ptr is foo.ptr)); // Passes
>>
>> I find it surprising because it looks like an entity does not have a 
>> well-behaving .ptr.
>>
>> (Aside: I think your code might be surprising to at least newcomers as 
>> well.)
> 
> That's a good reason to unrecommend/disallow enums with indirections. 

It can be useful to have enums with indirections available for 
metaprogramming, for intermediate data typed as mutable that is not 
necessarily required while running the program, yet can be read during 
compilation.

> The compiler should recommend/suggest using static immutable instead as 
> it does not have such oddities.

It types your data as immutable.

> The only advantage of enum is being 
> guaranteed to be known at compile-time

That is not an advantage of enum, as the same is true for static immutable.

> and they can be templatized (can 
> be also done for static immutable via eponymous template).
> I'd vote for a warning/error when the type of an enum has indirections 
> together with a pragma to switch the warning off for the rare case you 
> know exactly what you do.
> Just as Scott Meyers said: make it easy to use correctly and hard to use 
> incorrectly. Today it's easy to use incorrectly.
> 

Note that enums with indirections are already disallowed, except for 
dynamic arrays.