Mixin template confusion / compiler error.

[Ali Çehreli via Digitalmars-d-learn]

On 01/19/2017 12:41 AM, Chris Katko wrote:

 > 1 - Is there any way TO get the output 64,64?

You can mixin the entire statement. I used the ~ operator but you can 
use format() or the return value of a function as well:

     mixin("array_t!(" ~ sizer2D!() ~ ") case2;");
     // ...
     mixin("array3_t!(" ~ sizer2D!() ~ ") case6;");

With function call:

     mixin(makeDeclaration(/* ... */));

 > 2 - Is this very non-standard / unrecommended practice and there's a
 > much better way to do this?

There are other options like using literals like 64. Perhaps an 
AliasSeq!(64, 64) could be useful.

 > enum MAP_SIZE
 >     {
 >     PLANET = 2048,
 >     SHIP = 256,
 >     SHUTTLE = 64,
 >     (etc)
 >     } //this could also be translated to an array lookup. ala SHIP = 0,
 > SHUTTLE = 1, etc. with an array holding the sizes.
 >
 > and then I pass MAP_SIZE, into a map class, which then builds layers
 > into that map based on the MAP_SIZE. The layers are statically sized at
 > compile-time by translating a given MAP_SIZE down to the actual required
 > dimensions.
 >
 > So in plain English: Based on a MAP_SIZE, the inner structures are all
 > sized appropriately at compile-time.

I think the best way of doing this is by producing the entire code as 
string but look at the implementation of std.bitmanip.bitfields to see 
how it's actually a mixin template than contains an enum, I think to 
prevent name-polluting the scope that it's mixed in.

 > "no commas" seem so arbitrary from an abstract, novice
 > perspective.

I think AliasSeq is your best bet in that case.

 > What if I was pre-processing English statements which include
 > commas?

Of course you can do that as strings but mixed-in code must obey the 
spec and it must be "a valid StatementList". In other words, D's string 
mixins are the same as C's macros.

Ali