In CTFE it seems. Only tested with DMD on Windows though. Is this a known limitation, or a bug, I couldn't find anything that seemed to match it in the bugzilla.


import std.array;

struct DataAndView
{
	int[] data, view;

	this(int x)
	{
		data = [1, 2, 3, 4, 5];
		view = data[x .. $];
	}
}

unittest
{
	auto a = DataAndView(1);
	assert (sameTail(a.data, a.view));
	enum b = DataAndView(1);
	assert (!sameTail(b.data, b.view));
}

>         enum b = DataAndView(1);
>         assert (!sameTail(b.data, b.view));

I suppose it's because enums are manifest constants: the value they
represent is 'copy-pasted' anew everywhere it appears in the code. So
for arrays and associative arrays, it means recreating a new value
each and every time.
In your case, your code is equivalent to:

assert (!sameTail(DataAndView(1).data,DataAndView(1).view));

And the two DataAndView(1), being completely separated, do not have
the same tail.

On Thu, 05 Jun 2014 15:56:00 -0400, Philippe Sigaud via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:

>>         enum b = DataAndView(1);
>>         assert (!sameTail(b.data, b.view));
>
> I suppose it's because enums are manifest constants: the value they
> represent is 'copy-pasted' anew everywhere it appears in the code. So
> for arrays and associative arrays, it means recreating a new value
> each and every time.
> In your case, your code is equivalent to:
>
> assert (!sameTail(DataAndView(1).data,DataAndView(1).view));
>
> And the two DataAndView(1), being completely separated, do not have
> the same tail.

Yes, this should work (and execute the initializer at compile time):

static b = ...

-Steve

On 05/06/2014 8:56 PM, Philippe Sigaud via Digitalmars-d-learn wrote:
>>          enum b = DataAndView(1);
>>          assert (!sameTail(b.data, b.view));
>
> I suppose it's because enums are manifest constants: the value they
> represent is 'copy-pasted' anew everywhere it appears in the code. So
> for arrays and associative arrays, it means recreating a new value
> each and every time.
> In your case, your code is equivalent to:
>
> assert (!sameTail(DataAndView(1).data,DataAndView(1).view));
>
> And the two DataAndView(1), being completely separated, do not have
> the same tail.
>

Ah, Isee, that does kinda make sense ^^ A re-factoring we go...

A...

On 06/06/2014 8:52 AM, Alix Pexton wrote:

>>
>> And the two DataAndView(1), being completely separated, do not have
>> the same tail.
>>
>
> Ah, Isee, that does kinda make sense ^^ A re-factoring we go...
>

However, the code that originally tripped over this issue had the call to sameTail in the struct's invariant, and I don't seem to be able to reproduce that with the obvious reduced code...

Still, Thanks!

A...

On 05/06/2014 8:58 PM, Steven Schveighoffer wrote:
> On Thu, 05 Jun 2014 15:56:00 -0400, Philippe Sigaud via
> Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>
>>>         enum b = DataAndView(1);
>>>         assert (!sameTail(b.data, b.view));
>>
>> I suppose it's because enums are manifest constants: the value they
>> represent is 'copy-pasted' anew everywhere it appears in the code. So
>> for arrays and associative arrays, it means recreating a new value
>> each and every time.
>> In your case, your code is equivalent to:
>>
>> assert (!sameTail(DataAndView(1).data,DataAndView(1).view));
>>
>> And the two DataAndView(1), being completely separated, do not have
>> the same tail.
>
> Yes, this should work (and execute the initializer at compile time):
>
> static b = ...
>
> -Steve

Ah, the problem with static is that I want to use the values at compile time to create other values. Using static puts construction between compile time and run time. Initialising in static this means that the symbols need to be declared without initializers and that means not disabling default construction ><

A...

On Friday, 6 June 2014 at 08:17:43 UTC, Alix Pexton wrote:
> On 05/06/2014 8:58 PM, Steven Schveighoffer wrote:
>> On Thu, 05 Jun 2014 15:56:00 -0400, Philippe Sigaud via
>> Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>>
>>>>        enum b = DataAndView(1);
>>>>        assert (!sameTail(b.data, b.view));
>>>
>>> I suppose it's because enums are manifest constants: the value they
>>> represent is 'copy-pasted' anew everywhere it appears in the code. So
>>> for arrays and associative arrays, it means recreating a new value
>>> each and every time.
>>> In your case, your code is equivalent to:
>>>
>>> assert (!sameTail(DataAndView(1).data,DataAndView(1).view));
>>>
>>> And the two DataAndView(1), being completely separated, do not have
>>> the same tail.
>>
>> Yes, this should work (and execute the initializer at compile time):
>>
>> static b = ...
>>
>> -Steve
>
> Ah, the problem with static is that I want to use the values at compile time to create other values. Using static puts construction between compile time and run time. Initialising in static this means that the symbols need to be declared without initializers and that means not disabling default construction
> ><
>
> A...

Immutables should be usable at compile time and not allocate a new instance on every use when in module scope.

On Fri, 06 Jun 2014 06:14:30 -0400, Rene Zwanenburg <renezwanenburg@gmail.com> wrote:

> On Friday, 6 June 2014 at 08:17:43 UTC, Alix Pexton wrote:
>> On 05/06/2014 8:58 PM, Steven Schveighoffer wrote:

>>>
>>> Yes, this should work (and execute the initializer at compile time):
>>>
>>> static b = ...
>>
>> Ah, the problem with static is that I want to use the values at compile time to create other values. Using static puts construction between compile time and run time.

Not exactly (at least I don't think). The static initializer itself is generated at compile time. But the assignment to the static variable is done at run time.

>> Initialising in static this means that the symbols need to be declared without initializers and that means not disabling default construction
>> ><
>
> Immutables should be usable at compile time and not allocate a new instance on every use when in module scope.

I was about to say this. But immutable can have its own set of issues. If you want strictly compile-time generation of data, then immutable is the way to go.

But if you want to use it at runtime as well, immutable can hamper some things. I'm sure your example is a very small or reduced snippet of what you are actually doing.

-Steve

On 06/06/2014 7:39 PM, Steven Schveighoffer wrote:
> On Fri, 06 Jun 2014 06:14:30 -0400, Rene Zwanenburg
> <renezwanenburg@gmail.com> wrote:
>
>>
>> Immutables should be usable at compile time and not allocate a new
>> instance on every use when in module scope.
>
> I was about to say this. But immutable can have its own set of issues.
> If you want strictly compile-time generation of data, then immutable is
> the way to go.
>
> But if you want to use it at runtime as well, immutable can hamper some
> things. I'm sure your example is a very small or reduced snippet of what
> you are actually doing.
>
> -Steve

I re-factored my actual code to not need the slices at all as no matter how I tried to use them at compile time it broke one of my invariants.I now have enums that I can use at compile time to generate more enums (via set operations, etc) and at runtime, so I'm happy.

A...

On 06/06/2014 7:39 PM, Steven Schveighoffer wrote:
> On Fri, 06 Jun 2014 06:14:30 -0400, Rene Zwanenburg
> <renezwanenburg@gmail.com> wrote:
>> Immutables should be usable at compile time and not allocate a new
>> instance on every use when in module scope.
>
> I was about to say this. But immutable can have its own set of issues.
> If you want strictly compile-time generation of data, then immutable is
> the way to go.
>
> But if you want to use it at runtime as well, immutable can hamper some
> things. I'm sure your example is a very small or reduced snippet of what
> you are actually doing.
>
> -Steve

Something I read in Adam's D Cookbook (somewhere in chapter 9) got me thinking that I am on the wrong track with the code I was talking about here.

My new plan is to make the values that are currently passes to the structs' constructors into enums, then make the instances of the structs into static immutables. I'll need some factory methods in my struct but nothing to taxing.

Thanks again for your advice.