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