One case of array assignments
Timon Gehr
timon.gehr at gmx.ch
Mon Mar 18 15:59:56 PDT 2013
On 03/18/2013 11:52 PM, monarch_dodra wrote:
> On Monday, 18 March 2013 at 22:33:17 UTC, Timon Gehr wrote:
>> On 03/18/2013 10:45 PM, monarch_dodra wrote:
>>> ...
>>>
>>> ubyte[4096] x = repeat( cast(ubyte)0 )[ 0 .. 4096 ].array();
>>>
>>> This can be used as-is inside normal code. Hwoever, array is not
>>> CTFE-able, so it can't work to define a struct T.init value.
>>
>> Which is annoying and should be fixed.
>
> Making array work with CTFE is a no-go, as array's job is to run-time
> allocate a new array.
>
Uh. Its job is to collect a range into an array. Implementation details
are irrelevant.
> The syntax "T[N] = R.array" actually first transforms the range into a
> (dynamic) array, and then copies it into the static array. It is
> wasteful, but works. It is completely un-doable at compile time though.
>
You mean impossible? Of course it is possible.
> Now, if we had "staticArray(R, Sizes)(R)" transforms a range into an
> array whose size is know at compile time, then that's another story.
> It'd be more efficient at run-time, and CTFE-able
>
Sizes should go first.
> 1) Do we want such a weird and specific function? Or is that just
> premature optimization? I mean, is there a real need?
Use 'copy'.
> 2) Given CTFE's bug of "mutation implies duplication", I'm unsure
> providing such a function would be wise.
DMD bug, not CTFE bug.
More information about the Digitalmars-d
mailing list