Inheritance is broken

[BradleyChatha]

(This is assuming that #42 is merged.)

The new infogen package provides the internal getCommandArguments template, which provides an AliasSeq of each symbol within a command that describes a JCLI argument.

Now the issue is, D doesn't like it when symbols of members from different types are together within any form of template.

So, if you take a look at the output for the inheritance example, you can see the AliasSeq contains symbols for both the base type, as well as the type inheriting from the base type, causing the compiler to throw a fit.

The current/old way JCLI handles getting args avoided this issue, as it uses a different method for obtaining these arguments, however it feels like such a ballache to rewrite a rewrite just to work around a language/compiler limitation for a relatively small feature.

Mitigation

I haven't tested this yet, but if one were to use mixin templates and structs in place of base types and inheriting types, it should work?

e.g.

abstract class Base
{
    @CommandNamedArg("v")
    bool verbose;
}

@CommandDefault
final class Comm : Base
{
}

Would become

mixin template Base()
{
    @CommandNamedArg("v")
     bool verbose;
}

@CommandDefault
struct Comm
{
    mixin Base;
}

Although knowing my luck, it'd still complain :(