Namespace polluted by header-only implementations of platform APIs

[erlingrj]

In the work with introducing environments in the C target I found it necessary for lf_types.h to include platform.h, this means that the functions defined in platform.h will be in scope for the user. This was something @petervdonovan avoided with this PR I believe: #189.

The real problem isn't putting platform.h in scope, but rather that several platform APIs, e.g. for Windows implement a lot of stuff in the header files, and thus needs to include a bunch of windows header files which can create naming conflicts. Does anyone know why header-only implementations were chosen? To me it seems a lot cleaner to provide the implementation in separate source files which then can include the windows headers and not expose those further.

[petervdonovan]

Yep, this is a problem. #189 probably represents all I have to say about windows.h (edit: and more generally about why I want to include as few things in the default namespace as possible). On the internet you can find other people who also vent about windows.h, for example in the comments here. There might be a way to mitigate the problem using

#define WIN32_LEAN_AND_MEAN

but of course it isn't in our power to fix windows.h.

[erlingrj]

But is there any reason that windows.h must be included for any files except lf_windows_support.c?

[petervdonovan]

Oh, I understand your question now. I do not know of any particular reason for that. I think something like what you describe was considered as an alternative solution in #189.