'version'-based code selection

[Jonathan M Davis]

On Sunday, June 2, 2019 11:43:09 AM MDT Anonymouse via Digitalmars-d-learn 
wrote:
> On Saturday, 1 June 2019 at 07:46:40 UTC, Jonathan M Davis wrote:
> > For the most part though, you don't declare your own version
> > identifiers. It sometimes makes sense, but usually, version
> > identifiers are used for versioning code based on the platform
> > or architecture that it's compiled on. They're really only
> > intended to be a saner version of #ifdefs, and if you're doing
> > anything fancy with them, you're really not using them as
> > intended and are probably going to have problems.
>
> I use versioning pervasively to make features opt-in/opt-out at
> compile-time.
>
> Like so, from dub.json:
>
>      "versions":
>      [
>          "AsAnApplication",
>          "WithAdminPlugin",
>          "WithAutomodePlugin",
>          "WithBashQuotesPlugin",
>          "WithChanQueriesService",
>          "WithChatbotPlugin",
>          "WithConnectService",
>          "WithCTCPService",
>          "WithHelpPlugin",
>          "WithNotesPlugin",
>          "WithPersistenceService",
>          "WithPipelinePlugin",
>          "WithPrinterPlugin",
>          "WithQuotesPlugin",
>          "WithSedReplacePlugin",
>          "WithSeenPlugin",
>          "WithWebtitlesPlugin"
>      ],
>
> ---
>
> module foo;
>
> version(WithFoo):
>
> // ...
>
> Is this recommended against? It's a very convenient way of
> enabling and disabling modules outright, since (by default) dub
> eagerly compiles everything it sees. I haven't had any problems
> with it as of yet, at the very least.

Personally, I wouldn't be in favor of doing much in the way of enabling or
disabling features in a library or application in such a manner, but if
you're going to do it, then version identifiers would be appropriate.

However, you do need to watch out, because such an approach runs the risk of
problems if you end up with a project depending on libraries that depend on
your library, because they may not be compiled with the same set of version
identifiers. I'm not sure how dub handles that (probably by considering it a
conflict), but without any form of conflict resolution (or you have a form
of conflict resolution that doesn't catch this issue), you run the risk of
modules being imported with one set of version identifiers but actually
compiled with another. In some situations, that will result in a linker
error, but in others, it's just going to result in the code not behaving as
expected. It's less of an issue if the version identifiers are for an
application rather than a library. Also, if you're versioning out entire
modules rather than pieces of modules, you're likely to be less at risk of
subtle problems, since then you'll just get large stuff missing, and linking
will fail, whereas if you're using such version identifiers within code
(e.g. changing the body of a function), then you run a high risk of subtle
problems.

Personally, if I were writing a library with optional stuff, I'd make the
optional stuff into sub-modules and try to avoid using version identifiers.
I might do it for an application though, since in that case, you wouldn't be
dealing with sub-modules, and you're not dealing with anything depending on
your code, just controlling what ends up in the executable.

- Jonathan M Davis