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.

On 02.09.2017 01:37, Q. Schroll wrote:
> On Friday, 1 September 2017 at 23:13:50 UTC, Q. Schroll wrote:
>> [..]
>> Just as Scott Meyers said: make it easy to use correctly and hard to use incorrectly. Today it's easy to use incorrectly.
> 
> While
>    enum foo = [1,2,3];
>    assert(foo is foo);
> fails,
>    enum bla = "123";
>    assert(foo is foo);
> passes.
> 
> Enhancement request submitted: https://issues.dlang.org/show_bug.cgi?id=17799
> 
> Unfortunately after I found out the second one does not have to do with mutability. Making foo immutable(int)[] does not change anything. It only works for const(char)[], immutable(char)[], and probably w/dchar friends. That's odd.

This is called string pooling. This passed too:

void main(){
    assert("123" is "123");
}

D (at least sometimes) allows the identities of different immutable locations to become conflated.