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.
