A pattern I'd like to see more of - Parsing template parameter tuples

[Ethan]

On Monday, 21 May 2018 at 14:36:32 UTC, Jacob Carlborg wrote:
> enum Options options = { foo: true, bar: false, a: 42, b:  
> "guess what this does" };
> SomeObject!options o;

Yeah, so this is one reason why I went the parsing way.

enum Options Options1 = { foo: false, a: 5 };
SomeObject!Options1 object1;

enum Options Options2 = { foo: true, b: "Totally different" };
SomeObject!Options2 object2;

Repeat ad infinitum for each slightly different configuration you 
want. I always make the point of programmers being lazy by 
definition, and not being able to do something as simple as 
declare a type with a single statement is an clear example of 
reducing usability - which is a critical consideration the lazier 
a programmer is.

(As mentioned earlier in the thread, template parameter naming 
would make this entire thing irrelevant. As would being able to 
inline initialise a struct with named variables.)

Still, there's a few other things going on with my method. The 
EnumOptions class turns any enumeration in to a bitfield 
(regardless of underlying type). My own bitfield object in 
Binderoo does not have the limitations of std.bitmanip.bitfields 
as the type it creates internally is a ubyte[Size] aligned and 
padded out to byte boundaries. An enum declaration of any length 
is thus kosher. So perhaps EnumBitfield is the better name for 
the object. Using it in such a way is essentially more used to 
change default behaviour more than specify behaviour to begin 
with.

It's also an enabler. My Binderoo example at the bottom of my 
original post has multiple parameters of multiple different 
types. But what if I need to add more to it? Easy enough to add a 
variable to an options structure, you might think. But what if I 
need a tuple of types? Then the options structure becomes 
templated to hold the tuple. And so on and so forth. Parsing 
template parameters doesn't lock you in to such unintended design 
pattern consequences.

Parsing parameters also solves a problem I come across a bit too 
often - the desire to have multiple variable parameter sets as 
template parameters. Using that light wrapper template method 
also ensures that I can parse and sort parameters to cut down on 
unnecessary template reinstantiation.