enum pointers or class references limitation

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Fri Sep 1 16:33:24 PDT 2017


On 01.09.2017 20:48, Dmitry Olshansky wrote:
> On Thursday, 31 August 2017 at 14:28:57 UTC, Ali Çehreli wrote:
>> On 08/31/2017 01:52 AM, Nicholas Wilson wrote:
>>
>>> I think Timon is referring to:
>>>
>>> enum int[] foo = [1,2,3];
>>>
>>> auto bar = foo;
>>> auto baz = foo;
>>>
>>> assert(!(bar is baz)); // Passes
>>
>> Even better:
>>
>>     enum int[] foo = [1,2,3];
>>     assert(!(foo is foo)); // Passes
>>
> 
> I guess
> 
> assert(!([1,2,3] is [1,2,3]));
> 
> Which is exactly what enum expands to and totally expected.

I know what it does and do expect it. I still consider it problematic.
It's conceivable that someone just wants an enum slice to statically 
allocated array data (or a enum struct instance that has a field that is 
a statically allocated array, etc.). The enum/array literal design makes 
this impossible.

> Where is the surprise?
My main point is that I don't see why a ctRegex should runtime-allocate 
a class instance at each usage site. (And if it does not, the difference 
to array literals is not so easy to justify.)



But, there are a number of perhaps surprising behaviors of array 
literals at compile time that come to mind, some, but not all closely 
related to the issue at hand:

struct S{ int[] x; }
static assert(S([1,2,3]) is S([1,2,3])); // ok
auto x = S([1,2,3]), y = S([1,2,3]);

struct C{ int[] x; this(int[] x){ this.x=x; } }
static assert(new C([1,2,3]).x is new C([1,2,3]).x); // ok
static assert((){
     auto c=new C([1,2,3]);
     auto d=new C([1,2,3]);
     assert(c.x is d.x);
     c.x[0]=2;
     assert(c.x !is d.x);
     return true;
}()); // ok

enum s = S([1,2,3]);
immutable t = S([1,2,3]);
enum u = t;
void main()@nogc{
     assert(x is y); // fails
     // auto v = s; // error: gc allocation
     auto w1 = t; // ok
     // auto w2 = u; // error (!)
}

Basically, I think implicitly making expressions confused about their 
aliasing is just not a good idea. You can see that your: 'enum is just 
evaluate this expression at the usage site' is not the full story as 
otherwise w1 and w2 would behave the same.


More information about the Digitalmars-d mailing list