stops compiling

[BCS]

load the data into an array and stream it into the AA at runtime.

uint[2][] foo =
[
[1,2],
[3,4],
[5,6],
...
];

uint[uint] f;
static this()
{
	foreach(uint a; foo)
		f[a[0]]=a[1];
}

pros:
	fewer function calls
	less code
	no scripting needed
	well maybe a bit of formatting, awk, sed or your scripting engine
	...


Before you say it, an array of struct could be used to make this work with any 
set of types.


<script>
PRE:
define uint X;
X[X] f;
static this()
{
	foreach(X a; foo)
		f[a[0]]=a[1];
}
uint[2][] foo = [
POST:
];
ITEM:
[$(x)u,$(y)u],
</script>



debugger wrote:
> In article <dvtehj$1pj$1 at digitaldaemon.com>, Unknown W. Brackets says...
> 
>>Either way, 16,000 statements in the same scope are an obvious example 
>>of bad coding style ::).
> 
> I invite you to describe your _better_ coding style under aproximately following
> restriction.
> 
> You have to code a script used by a generator that offers you three definition
> facilities: PRE, POST and ITEM and you must implement a sparsely populated
> function f from natural numbers to natural numbers. Where sparsely means at most
> 10,000,000 elements out of 4,000,000,000 possible elements and the values of the
> pairs for the function are given as $(x) and $(y)
> 
> My _bad_ style looks like this:
> 
> <script>
> PRE:
> define uint X;
> define uint Y;
> Y[X] f;
> void init( uint x, uint y){
> f[cast(X)x]=cast(Y)y;
> }
> static this(){
> POST:
> }
> ITEM:
> init($(x)u,$(y)u); 
> </script>
> 
> That are nine lines to understand and maintain.
> 
> In case you will accept this invitation in addition to your coding solution I
> expect a sound argument, why your proposed _better_ coding style will spare a
> significant amount of maintenance man time.
> 
> Otherwise it should be clear who of us is a warrior.
> 
>