I've been running into this problem on consoles. I'd vote for creating a standard, only creating new identifiers according to that standard, and also adding standardised versions of existing identifiers (leaving also the ones don't conform, possibly remove them in D3)
The __APPLE__ one is a problem, how to identify iOS? OS8/9? I've been tinkering with PSP... what about Android, PS3, XBox(/360), etc... Some of these platforms exist on multiple architectures... how to distinguish the architecture from the platform? Standardisation of arch names? On 7 November 2011 03:33, Jonathan M Davis <[email protected]> wrote: > On Sunday, November 06, 2011 16:17:59 Walter Bright wrote: > > And finally, there is no such thing as a "sane" version identifier > scheme. > > For one thing, OS vendors do not pick sane names. OS/2 is not an > > identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors pick > > any sane identifiers for their own systems (look at what Sun did). > > > > Even if someone comes up with a naming scheme for D that most agree is > sane, > > intuitive, and attractive, switching to it would again silently break a > > large swath of existing D code. D cannot advance by constantly breaking > > things. > > I think that what it comes down to is that most D programmers are looking > for > consistency and don't care what C is doing with its version identifiers. > You > have to look up what they are regardless, since even if you know the C > identifiers and you know that D is trying to follow them, there's still no > guarantee that they're the same. It may not be worth making breaking > changes > (e.g. changing linux to Linux) at this point, but at minimum, I'd argue > that > new version identifiers should be more consistent. And I believe that some > have > argued in the pas that we should just add Linux to make it consistent, but > leave linux to avoid code breakage (which has the upside of increasing > consistency but the downside of creating two version identifiers for the > same > thing). > > - Jonathan M Davis >
