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.
