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.

Reply via email to