On Wednesday, 4 December 2013 at 13:45:35 UTC, Jakob Ovrum wrote:
> On Wednesday, 4 December 2013 at 13:16:35 UTC, monarch_dodra wrote:
>> Problem is that doing this returns an immutable type, which isn't quite the same as a ctfe variable (which was the initial goal, as far as I'm concerned)
>
> Immutable "global" variables with initializers are readable at compile-time (as the initializers are required to be readable at compile-time). I don't know what you mean by "CTFE variable".

I mean that:

auto a = eval!(1 + 2);
a += 1; // <= cannot modify immutable expression 3

Should work.

Or that:

auto arr = eval!(iota(0, 10).array());
//arr is expected to be int[]
//NOT immutable(int[])
arr[0] = 10; //Error: cannot modify immutable expression arr[0]

Long story short, just because something is pre-calculated with CTFE doesn't mean it can't be mutable.

For example:
enum a10 = iota(0, 10).array();
auto arr1 = a10;
auto arr2 = a10;
assert(arr1 !is arr2);
assert(arr1 == arr2);
arr1[0] = 10;
assert(arr1 != arr2);


> Using enum has issues, as elaborated upon by Don in this enhancement request[1] (for reference; I'm sure you remember them).
>
> [1] http://d.puremagic.com/issues/show_bug.cgi?id=10950

I absolutely remember that. But I still believe that is a *bug*, and not an enhancement request. Buggy behavior should not dictate our design.

On 4.12.2013. 13:08, Jakob Ovrum wrote:
> On Wednesday, 4 December 2013 at 11:54:08 UTC, luka8088 wrote:
>> Eval comes from examples of http://dlang.org/function.html#interpretation
> 
> A couple of notes:
> 
> The use of a variadic template parameter instead of an alias parameter
> is misleading because the template does not need to support types in the
> first place (and the proposed implementation would fail when given a type).

Yeah. I guess it is a documentation (example) issue.

> 
> The name used on dlang.org is correctly using a lowercase `e`, according to the naming convention for templates that always evaluate to values/variables as opposed to types.

Oh, I didn't know that. Thanks!

On 4.12.2013. 16:28, monarch_dodra wrote:
> On Wednesday, 4 December 2013 at 13:45:35 UTC, Jakob Ovrum wrote:
>> On Wednesday, 4 December 2013 at 13:16:35 UTC, monarch_dodra wrote:
>>> Problem is that doing this returns an immutable type, which isn't quite the same as a ctfe variable (which was the initial goal, as far as I'm concerned)
>>
>> Immutable "global" variables with initializers are readable at compile-time (as the initializers are required to be readable at compile-time). I don't know what you mean by "CTFE variable".
> 
> I mean that:
> 
> auto a = eval!(1 + 2);
> a += 1; // <= cannot modify immutable expression 3
> 
> Should work.

I don't think so. With type inference a is immutable.

int a = eval!(1 + 2);

Works.

> 
> Or that:
> 
> auto arr = eval!(iota(0, 10).array());
> //arr is expected to be int[]
> //NOT immutable(int[])
> arr[0] = 10; //Error: cannot modify immutable expression arr[0]
> 
> Long story short, just because something is pre-calculated with CTFE doesn't mean it can't be mutable.
> 
> For example:
> enum a10 = iota(0, 10).array();
> auto arr1 = a10;
> auto arr2 = a10;
> assert(arr1 !is arr2);
> assert(arr1 == arr2);
> arr1[0] = 10;
> assert(arr1 != arr2);
> 
> 
>> Using enum has issues, as elaborated upon by Don in this enhancement request[1] (for reference; I'm sure you remember them).
>>
>> [1] http://d.puremagic.com/issues/show_bug.cgi?id=10950
> 
> I absolutely remember that. But I still believe that is a *bug*, and not an enhancement request. Buggy behavior should not dictate our design.

On Thursday, 5 December 2013 at 07:36:30 UTC, luka8088 wrote:
> On 4.12.2013. 16:28, monarch_dodra wrote:
>> 
>> I mean that:
>> 
>> auto a = eval!(1 + 2);
>> a += 1; // <= cannot modify immutable expression 3
>> 
>> Should work.
>
> I don't think so. With type inference a is immutable.
>
> int a = eval!(1 + 2);
>
> Works.

Right, but that's my point. If you use an enum, as opposed to a global immutable, it *does* work.

Also, your rebuke works for the trivial int type, but not for a more complicated type with indirection, such as a dynamic array, and even less so a struct with a complex structure.

--------

Having a template that stores a single global-static-immutable value also has its uses (which I have *also* used in phobos, more than once. But:
a) It's for a different use case.
b) The use cases where specific enough that not having "on-the-fly" template to do it.