<p dir="ltr">On 12 Dec 2014 21:50, "Sean Kelly via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On Friday, 12 December 2014 at 15:47:09 UTC, Joakim wrote:<br>
>><br>
>><br>
>> 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.<br>
>><br>
>> Why not just declare them once for Posix and then specialize for a particular OS later on when necessary<br>
><br>
><br>
> Because therein lies madness.<br>
><br>
><br>
><br>
>> as seems to have been done in these instances?<br>
><br>
><br>
> I could be convinced to allow required function prototypes to be<br>
> in version(Posix) blocks, but never data definitions.  And even<br>
> putting function prototypes in common version blocks risks link<br>
> errors.  I would *love* it if platforms that contained a header<br>
> actually implemented all of the functions required by a specific<br>
> tag (required, xopen, etc) when choosing any one from that tag,<br>
> but even this can't be relied upon.<br>
><br>
> In my C/C++ code I have compatibility modules that conditionally<br>
> implement missing functions based on the platform and libc<br>
> version, but this is so not fun. Particularly when you're<br>
> targeting as many platform as D is trying to.  So really, you<br>
> should never see a version(Posix) block in core.sys.posix,<br>
> because it means that for some platform, compilation/linking will<br>
> fail.<br>
></p>
<p dir="ltr">Except maybe at the top with extern(Posix):</p>
<p dir="ltr">The compiler (or build environment) can at least work out that it is targeting a vaguely POSIX platform.</p>