On 12 Dec 2014 21:50, "Sean Kelly via Digitalmars-d" < [email protected]> wrote: > > On Friday, 12 December 2014 at 15:47:09 UTC, Joakim wrote: >> >> >> It seems like pointless repetition and there are many more examples of this, as I keep running into it when adding bionic/Android support. Martin suggested that it would be useful to have a default case that asserts for an unsupported OS, but many of these blocks don't have that either. >> >> Why not just declare them once for Posix and then specialize for a particular OS later on when necessary > > > Because therein lies madness. > > > >> as seems to have been done in these instances? > > > I could be convinced to allow required function prototypes to be > in version(Posix) blocks, but never data definitions. And even > putting function prototypes in common version blocks risks link > errors. I would *love* it if platforms that contained a header > actually implemented all of the functions required by a specific > tag (required, xopen, etc) when choosing any one from that tag, > but even this can't be relied upon. > > In my C/C++ code I have compatibility modules that conditionally > implement missing functions based on the platform and libc > version, but this is so not fun. Particularly when you're > targeting as many platform as D is trying to. So really, you > should never see a version(Posix) block in core.sys.posix, > because it means that for some platform, compilation/linking will > fail. >
Except maybe at the top with extern(Posix): The compiler (or build environment) can at least work out that it is targeting a vaguely POSIX platform.
