unnecessary OS redundancy in druntime

[Iain Buclaw via Digitalmars-d]

On 12 Dec 2014 21:50, "Sean Kelly via Digitalmars-d" <
digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141213/28729e6e/attachment.html>