Library settings, best practices?

[Vladimirs Nordholm]

Hello.

Pre-rant:
---------
I have a library to aid in development for the terminal. This 
library has to initialize some things before it can be used, and 
I run some code in `shared static this(){...}`. I believe in the 
most common case scenario my initializer should be run.

The initializer sets the terminal to allow input and better 
output performance, but makes the terminal not behave as usual.

I believe that sometimes, not all features (input and output) are 
wanted. As mentioned, to optimize output, some ANSI commands are 
called, which messes with ordinary `std.stdio.write(...)`. To get 
input via my library's functions a new thread is created, and 
some other things happen, which might not be desired.

Initially, I did have a initalizer function which the user had to 
call, but I myself often forgot to call the function when making 
a small program, and got stuck because the library didn't 
initalize.

Actual question:
----------------
Is there a best practice to enabling specific parts of a library?

Ideally I would prefer to not have them at all, but I myself 
sometime find it necessary to only use a part of the library.

Also as mentioned, I strongly prefer to not have the user call 
initializer functions themselves.

More ranting:
-------------
Some thoughts I have (which I'm not sure are the best way to 
approach this issue with) are:
* only parts of the library compile (like how `static if(...)` 
and `version (...)` works) depending on what parts should be used.
* put settings in a file in `dub.json/sdl`, or a separate 
settings file.

As a final note, I do not intend for my library to be like vim, 
with a million `#ifdef`s. Only the two main parts (input and 
output) should be available to enable/disable.

These are my thoughts, and any input is highly appreciated. If 
anyone has had experiences with similar issues before, please 
share them.

And if the absolute best way is to have user-called 
(de)initializers, then I guess I have to bite the sour apple ;^)

Best regards,
Vladimirs Nordholm