On 12 Dec 2014 21:50, "Sean Kelly via Digitalmars-d" <digitalmars-d@puremagic.com> 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.