Using "cast(enum)" for explicit request of ctfe

luka8088 luka8088 at owave.net
Wed Dec 4 23:36:29 PST 2013


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.



More information about the Digitalmars-d mailing list