www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Version Identifiers for Platforms / Architectures not supported by DMD

reply Iain Buclaw <ibuclaw ubuntu.com> writes:
I have had a recent pull request regarding the updating of some of GDC's OS
and Arch version identifiers.

https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version

Such changes include, aix -> AIX; ALPHA -> Alpha;  and a few more.


While I welcome any change suggestions, I would love to hear the opinion of D
users on the proposed change.


Regards
Iain
Nov 05 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 05, 2011 20:48:32 Iain Buclaw wrote:

 I have had a recent pull request regarding the updating of some of GDC's OS
 and Arch version identifiers.
 
 https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-ve
 rsion
 
 Such changes include, aix -> AIX; ALPHA -> Alpha;  and a few more.
 
 
 While I welcome any change suggestions, I would love to hear the opinion of
 D users on the proposed change.


dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, 
whereas Windows is Pascal-cased and OSX is all uppercase). Most of them, 
however, are Pascal-cased, so for consistency, it's probably better to make 
them all Pascal-cased, but given the lack of consistency and the fact that you 
don't necessarily get any errors when you use an incorrectly-spelled version 
identifier, you generally have to look it up regardless, and if you always have 
to look it up, the exact casing doesn't necessarily matter.

Still, I'd argue that version identifiers in general should just be Pascal-
cased since that seems to be the most common casing used, and ideally, they'd 
be consistent.

For acronyms, that would mean all uppercase, so assuming that AIX is an 
acronym, then AIX would be the correct way to go, and assuming that alpha 
isn't an acronym, then Alpha would be the correct way to go (I'm not 
particularly familiar with non-x86 architectures, so I don't know whether 
they're acronyms or not - though I'd guess that AIX is and Alpha isn't).

- Jonathan M Davis
Nov 05 2011
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 05-11-2011 22:07, Jonathan M Davis wrote:

 On Saturday, November 05, 2011 20:48:32 Iain Buclaw wrote:

 I have had a recent pull request regarding the updating of some of GDC's OS
 and Arch version identifiers.

 https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-ve
 rsion

 Such changes include, aix ->  AIX; ALPHA ->  Alpha;  and a few more.


 While I welcome any change suggestions, I would love to hear the opinion of
 D users on the proposed change.


 dmd's version identifiers are annoyingly variable (e.g. linux is camelcased,
 whereas Windows is Pascal-cased and OSX is all uppercase). Most of them,
 however, are Pascal-cased, so for consistency, it's probably better to make
 them all Pascal-cased, but given the lack of consistency and the fact that you
 don't necessarily get any errors when you use an incorrectly-spelled version
 identifier, you generally have to look it up regardless, and if you always have
 to look it up, the exact casing doesn't necessarily matter.

 Still, I'd argue that version identifiers in general should just be Pascal-
 cased since that seems to be the most common casing used, and ideally, they'd
 be consistent.

 For acronyms, that would mean all uppercase, so assuming that AIX is an
 acronym, then AIX would be the correct way to go, and assuming that alpha
 isn't an acronym, then Alpha would be the correct way to go (I'm not
 particularly familiar with non-x86 architectures, so I don't know whether
 they're acronyms or not - though I'd guess that AIX is and Alpha isn't).

 - Jonathan M Davis


That's exactly how it is. :)

- Alex
Nov 05 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/5/2011 2:07 PM, Jonathan M Davis wrote:

 dmd's version identifiers are annoyingly variable (e.g. linux is camelcased,
 whereas Windows is Pascal-cased and OSX is all uppercase).


What they do is follow the casing and spelling of the pre-defined macros of the 
local C compiler.
Nov 05 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:j95116$79g$1 digitalmars.com...

 On 11/5/2011 2:07 PM, Jonathan M Davis wrote:

 dmd's version identifiers are annoyingly variable (e.g. linux is 
 camelcased,
 whereas Windows is Pascal-cased and OSX is all uppercase).


 What they do is follow the casing and spelling of the pre-defined macros 
 of the local C compiler.


That makes it easy to remember! (Not!)
Nov 06 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 06-11-2011 13:07, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:j95116$79g$1 digitalmars.com...

 On 11/5/2011 2:07 PM, Jonathan M Davis wrote:

 dmd's version identifiers are annoyingly variable (e.g. linux is
 camelcased,
 whereas Windows is Pascal-cased and OSX is all uppercase).


 What they do is follow the casing and spelling of the pre-defined macros
 of the local C compiler.


 That makes it easy to remember! (Not!)


I have to say, following C compilers in macro definitions is more 
error-prone than just defining a more sane, standardized set of version 
identifiers. Not everyone writing D code will be familiar with C.

- Alex
Nov 06 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-11-06 04:04:22 +0000, Walter Bright <newshound2 digitalmars.com> said:


 On 11/5/2011 2:07 PM, Jonathan M Davis wrote:

 dmd's version identifiers are annoyingly variable (e.g. linux is camelcased,
 whereas Windows is Pascal-cased and OSX is all uppercase).


 
 What they do is follow the casing and spelling of the pre-defined 
 macros of the local C compiler.


I find this statement puzzling. According to 
<http://predef.sourceforge.net/preos.html>:

*  There's no OSX macro on OS X, just __APPLE__ and __MACH__.
*  There's no Solaris macro on Solaris, only 'sun' and '__sun'.
*  There's no Windows/Win32/Win64 macro on Windows, there's 
__WINDOWS__/_WIN32/_WIN64.
*  There's no FreeBSD macro on FreeBSD, instead you have __FreeBSD__.

Beside linux, I don't see any of the predefined version identifiers 
corresponding to the platform's standard C macros.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Nov 06 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2011 6:40 AM, Michel Fortin wrote:

 On 2011-11-06 04:04:22 +0000, Walter Bright <newshound2 digitalmars.com> said:


 On 11/5/2011 2:07 PM, Jonathan M Davis wrote:

 dmd's version identifiers are annoyingly variable (e.g. linux is camelcased,
 whereas Windows is Pascal-cased and OSX is all uppercase).


 What they do is follow the casing and spelling of the pre-defined macros of
 the local C compiler.


 I find this statement puzzling. According to
 <http://predef.sourceforge.net/preos.html>:

 * There's no OSX macro on OS X, just __APPLE__ and __MACH__.
 * There's no Solaris macro on Solaris, only 'sun' and '__sun'.
 * There's no Windows/Win32/Win64 macro on Windows, there's
 __WINDOWS__/_WIN32/_WIN64.
 * There's no FreeBSD macro on FreeBSD, instead you have __FreeBSD__.

 Beside linux, I don't see any of the predefined version identifiers
 corresponding to the platform's standard C macros.


Based on my research:

         _WIN32          Microsoft NT, Windows 95, Windows 98, Win32s, Windows
2000
         _WIN64          Windows for AMD64
         linux           Linux
         __APPLE__       Mac OSX
         __FreeBSD__     FreeBSD
         __OpenBSD__     OpenBSD
         __sun&&__SVR4   Solaris, OpenSolaris (yes, both macros are necessary)

Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked awful 
:-) and are unnecessary for D since the version tags are in a separate
namespace.

Had to come up with one for Solaris.

APPLE is hopelessly generic, considering Apple has produced many operating
systems.

__WINDOWS__ is not what DMC uses. See

    http://www.digitalmars.com/ctg/predefined.html

Some people have protested that I have "trivialized" Linux by using "linux",
but 
I am perplexed why that's ok for gcc but not for D.

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.
Nov 06 2011
next sibling parent reply Manu <turkeyman gmail.com> writes:
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 <jmdavisProg gmx.com> 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
Nov 07 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-07 09:23, Manu wrote:

 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?


Perhaps "Mac" for Mac OS and "darwin" for Mac OS X and iOS. Both Mac OS 
X and iOS builds on the same foundation.


 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?


There are version identifiers for different architectures as well, e.g. 
X86, X86_64 and so on.

-- 
/Jacob Carlborg
Nov 07 2011
parent reply Manu <turkeyman gmail.com> writes:
 Both Mac OS X and iOS builds on the same foundation.



True-ish, but they're not even slightly the same from a developer
perspective. People often make that mistake, where technologies are
similar, but neglect the fact that you have to do fundamentally different
things on the devices.
They need to be distinguished. If darwin is defined, then it ALSO needs a
OSX/iOS for disambiguation in addition.



 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?


 There are version identifiers for different architectures as well, e.g.
 X86, X86_64 and so on.



Yes, but they need to be declared standard, and listed somewhere. If
they're not reliable, then you'll inevitably be in the same mess as cross
platform C apps where you need a global header that parses and munges a
huge pile of arbitrary defines into useful macros for your app.

For any platform/architecture, there should ALWAYS be available at least
identifiers for PLATFORM, OS, and ARCHITECTURE.
An identifier for TOOLCHAIN is often useful too, since different toolchains
for the same system might be slight different, eg. console game dev in
particular... GCC, SN, Codewarrior, proprietary compilers; all target
exactly the same thing, but require some toolchain specific code.

Basically I think if those three (I'd argue for 4) things aren't present,
standardised, and dependable, there will always eventually be the mess we
all love in the top of C header files.

For instance, the OSX example above, I'd suggest something like:
 PLATFORM = darwin
 OS = OSX/iOS
 ARCHITECTURE = X86/PPC/ARM
 TOOLCHAIN = [whatever]
Nov 07 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 07-11-2011 11:55, Manu wrote:

     Both Mac OS X and iOS builds on the same foundation.


 True-ish, but they're not even slightly the same from a developer
 perspective. People often make that mistake, where technologies are
 similar, but neglect the fact that you have to do fundamentally
 different things on the devices.
 They need to be distinguished. If darwin is defined, then it ALSO needs
 a OSX/iOS for disambiguation in addition.

         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?


     There are version identifiers for different architectures as well,
     e.g. X86, X86_64 and so on.


 Yes, but they need to be declared standard, and listed somewhere. If
 they're not reliable, then you'll inevitably be in the same mess as
 cross platform C apps where you need a global header that parses and
 munges a huge pile of arbitrary defines into useful macros for your app.

 For any platform/architecture, there should ALWAYS be available at least
 identifiers for PLATFORM, OS, and ARCHITECTURE.
 An identifier for TOOLCHAIN is often useful too, since different
 toolchains for the same system might be slight different, eg. console
 game dev in particular... GCC, SN, Codewarrior, proprietary compilers;
 all target exactly the same thing, but require some toolchain specific code.

 Basically I think if those three (I'd argue for 4) things aren't
 present, standardised, and dependable, there will always eventually be
 the mess we all love in the top of C header files.

 For instance, the OSX example above, I'd suggest something like:
   PLATFORM = darwin
   OS = OSX/iOS
   ARCHITECTURE = X86/PPC/ARM
   TOOLCHAIN = [whatever]


I'm not sure I see the idea in having a platform value separate from an 
OS value. Otherwise I agree; OS, architecture, and toolchain should 
always be identifiable.

- Alex
Nov 07 2011
parent Manu <turkeyman gmail.com> writes:
 I'm not sure I see the idea in having a platform value separate from an OS
 value. Otherwise I agree; OS, architecture, and toolchain should always be
 identifiable.



Platform identifies some sort of common foundation; as dawrin is to OSX/iOS

Linux running on an xbox is still running on an xbox, and definitely
distinct from linux running on any old pc.
Nov 07 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-07 11:55, Manu wrote:

 True-ish, but they're not even slightly the same from a developer
 perspective. People often make that mistake, where technologies are
 similar, but neglect the fact that you have to do fundamentally
 different things on the devices.
 They need to be distinguished. If darwin is defined, then it ALSO needs
 a OSX/iOS for disambiguation in addition.


That's correct but it also depends on what you're developing. Say if you 
develop a library for handling strings (not drawing) they would probably 
be exactly the same on Mac OS X and iOS.


 Yes, but they need to be declared standard, and listed somewhere. If
 they're not reliable, then you'll inevitably be in the same mess as
 cross platform C apps where you need a global header that parses and
 munges a huge pile of arbitrary defines into useful macros for your app.


This is a list of all predefined version identifiers: 
http://d-programming-language.org/version.html#PredefinedVersions


 For any platform/architecture, there should ALWAYS be available at least
 identifiers for PLATFORM, OS, and ARCHITECTURE.
 An identifier for TOOLCHAIN is often useful too, since different
 toolchains for the same system might be slight different, eg. console
 game dev in particular... GCC, SN, Codewarrior, proprietary compilers;
 all target exactly the same thing, but require some toolchain specific code.


What is "platform" in this case.


 Basically I think if those three (I'd argue for 4) things aren't
 present, standardised, and dependable, there will always eventually be
 the mess we all love in the top of C header files.

 For instance, the OSX example above, I'd suggest something like:
   PLATFORM = darwin
   OS = OSX/iOS
   ARCHITECTURE = X86/PPC/ARM
   TOOLCHAIN = [whatever]


Ok, so for linux it could be the following?

platform = linux
os = ubuntu
architecture = x86
tool chain = gcc

-- 
/Jacob Carlborg
Nov 07 2011
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 07-11-2011 13:29, Jacob Carlborg wrote:

 On 2011-11-07 11:55, Manu wrote:

 True-ish, but they're not even slightly the same from a developer
 perspective. People often make that mistake, where technologies are
 similar, but neglect the fact that you have to do fundamentally
 different things on the devices.
 They need to be distinguished. If darwin is defined, then it ALSO needs
 a OSX/iOS for disambiguation in addition.


 That's correct but it also depends on what you're developing. Say if you
 develop a library for handling strings (not drawing) they would probably
 be exactly the same on Mac OS X and iOS.


 Yes, but they need to be declared standard, and listed somewhere. If
 they're not reliable, then you'll inevitably be in the same mess as
 cross platform C apps where you need a global header that parses and
 munges a huge pile of arbitrary defines into useful macros for your app.


 This is a list of all predefined version identifiers:
 http://d-programming-language.org/version.html#PredefinedVersions


That list is, in fact, very out of date. I have some pending patches in 
my fork here: 
https://github.com/alexrp/d-programming-language.org/commits/master

I'll send those upstream when the GDC patch is merged.


 For any platform/architecture, there should ALWAYS be available at least
 identifiers for PLATFORM, OS, and ARCHITECTURE.
 An identifier for TOOLCHAIN is often useful too, since different
 toolchains for the same system might be slight different, eg. console
 game dev in particular... GCC, SN, Codewarrior, proprietary compilers;
 all target exactly the same thing, but require some toolchain specific
 code.


 What is "platform" in this case.


 Basically I think if those three (I'd argue for 4) things aren't
 present, standardised, and dependable, there will always eventually be
 the mess we all love in the top of C header files.

 For instance, the OSX example above, I'd suggest something like:
 PLATFORM = darwin
 OS = OSX/iOS
 ARCHITECTURE = X86/PPC/ARM
 TOOLCHAIN = [whatever]


 Ok, so for linux it could be the following?

 platform = linux
 os = ubuntu
 architecture = x86
 tool chain = gcc


- Alex
Nov 07 2011
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Manu (turkeyman gmail.com)'s article

 --001485ec112698f20204b120c415
 Content-Type: text/plain; charset=UTF-8
 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?


I don't see any real need to have identifiers for console platforms built into
the compiler.  As you'd pretty much always would be using a homebrew cross-
compiler, and can simply pass -version=PSP on the command-line in the build
command.
Nov 07 2011
parent Manu <turkeyman gmail.com> writes:
On 8 November 2011 00:33, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 == Quote from Manu (turkeyman gmail.com)'s article

 --001485ec112698f20204b120c415
 Content-Type: text/plain; charset=UTF-8
 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?


 I don't see any real need to have identifiers for console platforms built
 into
 the compiler.  As you'd pretty much always would be using a homebrew cross-
 compiler, and can simply pass -version=PSP on the command-line in the build
 command.


... I guess. But I reckon it's a bit of a pain in the arse to remember to
do that everywhere (and edit scripts all over the place when cross
compiling).
I don't really see why a platform specific toolchain wouldn't know what it
is, and define its self as such.

Not to mention, if you leave it up to the user to expect some arbitrary
version identifier passed into their code, you'll never find a standard
accepted by all code for a platform... it'll just be a total mess like C is
now.
I say it should be proactively selected to encourage standardisation on
one, and it should be asserted by the compiler automatically. 10 years of
arguing with different compilers and libs for the same platforms
disagreeing on how to identify the thing has taught me that much :/
Nov 07 2011
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 07-11-2011 01:17, Walter Bright wrote:

 On 11/6/2011 6:40 AM, Michel Fortin wrote:
  > On 2011-11-06 04:04:22 +0000, Walter Bright
 <newshound2 digitalmars.com> said:
  >
  >> On 11/5/2011 2:07 PM, Jonathan M Davis wrote:
  >>> dmd's version identifiers are annoyingly variable (e.g. linux is
 camelcased,
  >>> whereas Windows is Pascal-cased and OSX is all uppercase).
  >>
  >> What they do is follow the casing and spelling of the pre-defined
 macros of
  >> the local C compiler.
  >
  > I find this statement puzzling. According to
  > <http://predef.sourceforge.net/preos.html>:
  >
  > * There's no OSX macro on OS X, just __APPLE__ and __MACH__.
  > * There's no Solaris macro on Solaris, only 'sun' and '__sun'.
  > * There's no Windows/Win32/Win64 macro on Windows, there's
  > __WINDOWS__/_WIN32/_WIN64.
  > * There's no FreeBSD macro on FreeBSD, instead you have __FreeBSD__.
  >
  > Beside linux, I don't see any of the predefined version identifiers
  > corresponding to the platform's standard C macros.

 Based on my research:

 _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s, Windows 2000
 _WIN64 Windows for AMD64
 linux Linux
 __APPLE__ Mac OSX
 __FreeBSD__ FreeBSD
 __OpenBSD__ OpenBSD
 __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are necessary)

 Hence FreeBSD rather than freebsd or Freebsd. The underscores just
 looked awful :-) and are unnecessary for D since the version tags are in
 a separate namespace.

 Had to come up with one for Solaris.

 APPLE is hopelessly generic, considering Apple has produced many
 operating systems.

 __WINDOWS__ is not what DMC uses. See

 http://www.digitalmars.com/ctg/predefined.html

 Some people have protested that I have "trivialized" Linux by using
 "linux", but I am perplexed why that's ok for gcc but not for D.


My only actual complaint here would be the casing of the 'l'. The 
version identifier itself seems fine to me.


 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.


- Alex
Nov 07 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:j9784p$24tu$1 digitalmars.com...

 Based on my research:

         _WIN32          Microsoft NT, Windows 95, Windows 98, Win32s, 
 Windows 2000
         _WIN64          Windows for AMD64
         linux           Linux
         __APPLE__       Mac OSX
         __FreeBSD__     FreeBSD
         __OpenBSD__     OpenBSD
         __sun&&__SVR4   Solaris, OpenSolaris (yes, both macros are 
 necessary)

 Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked 
 awful :-) and are unnecessary for D since the version tags are in a 
 separate namespace.

 Had to come up with one for Solaris.

 APPLE is hopelessly generic, considering Apple has produced many operating 
 systems.

 __WINDOWS__ is not what DMC uses. See

    http://www.digitalmars.com/ctg/predefined.html


You're completely contradicting your claim here of having used the gcc 
idents. Obviously you changed the idents, and you had a reason for each one. 
There's pretty damn good reason for changing "linux" too.

At least Phobos is finally ditching the absolutely rediculous philosophy of 
"always use naming conventions from random other places, and don't ever even 
think about being internally-consistent".


 Some people have protested that I have "trivialized" Linux by using 
 "linux", but I am perplexed why that's ok for gcc but not for D.


Strawman.


 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).


You're really stretching to say those aren't "sane" names. They're just 
names, they're not even intended to be identifiers. To make identifiers 
*for* them, removing the illegal chars (and using a non-schizophrenic casing 
scheme) is an obvious and non-problematic solution. Picking *ONE* of them to 
be lowercased instead of upper camel cased like the rest (or any other 
inconsistent casing) isn't merely "not sane", it's also completely 
unnecessary.


 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.


Adding "Linux" as a preferred alternative to "linux" will not break large 
swaths of code.
Nov 07 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 07-11-2011 14:20, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:j9784p$24tu$1 digitalmars.com...

 Based on my research:

          _WIN32          Microsoft NT, Windows 95, Windows 98, Win32s,
 Windows 2000
          _WIN64          Windows for AMD64
          linux           Linux
          __APPLE__       Mac OSX
          __FreeBSD__     FreeBSD
          __OpenBSD__     OpenBSD
          __sun&&__SVR4   Solaris, OpenSolaris (yes, both macros are
 necessary)

 Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked
 awful :-) and are unnecessary for D since the version tags are in a
 separate namespace.

 Had to come up with one for Solaris.

 APPLE is hopelessly generic, considering Apple has produced many operating
 systems.

 __WINDOWS__ is not what DMC uses. See

     http://www.digitalmars.com/ctg/predefined.html


 You're completely contradicting your claim here of having used the gcc
 idents. Obviously you changed the idents, and you had a reason for each one.
 There's pretty damn good reason for changing "linux" too.

 At least Phobos is finally ditching the absolutely rediculous philosophy of
 "always use naming conventions from random other places, and don't ever even
 think about being internally-consistent".


 Some people have protested that I have "trivialized" Linux by using
 "linux", but I am perplexed why that's ok for gcc but not for D.


 Strawman.


 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).


 You're really stretching to say those aren't "sane" names. They're just
 names, they're not even intended to be identifiers. To make identifiers
 *for* them, removing the illegal chars (and using a non-schizophrenic casing
 scheme) is an obvious and non-problematic solution. Picking *ONE* of them to
 be lowercased instead of upper camel cased like the rest (or any other
 inconsistent casing) isn't merely "not sane", it's also completely
 unnecessary.


 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.


 Adding "Linux" as a preferred alternative to "linux" will not break large
 swaths of code.


Yes, this would be a good idea. This approach could deprecate 'linux' in 
favor of 'Linux' as 'darwin' was deprecated in favor of 'OSX'.

- Alex
Nov 07 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 07-11-2011 14:59, Alex Rønne Petersen wrote:

 On 07-11-2011 14:20, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com> wrote in message
 news:j9784p$24tu$1 digitalmars.com...

 Based on my research:

 _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s,
 Windows 2000
 _WIN64 Windows for AMD64
 linux Linux
 __APPLE__ Mac OSX
 __FreeBSD__ FreeBSD
 __OpenBSD__ OpenBSD
 __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are
 necessary)

 Hence FreeBSD rather than freebsd or Freebsd. The underscores just
 looked
 awful :-) and are unnecessary for D since the version tags are in a
 separate namespace.

 Had to come up with one for Solaris.

 APPLE is hopelessly generic, considering Apple has produced many
 operating
 systems.

 __WINDOWS__ is not what DMC uses. See

 http://www.digitalmars.com/ctg/predefined.html


 You're completely contradicting your claim here of having used the gcc
 idents. Obviously you changed the idents, and you had a reason for
 each one.
 There's pretty damn good reason for changing "linux" too.

 At least Phobos is finally ditching the absolutely rediculous
 philosophy of
 "always use naming conventions from random other places, and don't
 ever even
 think about being internally-consistent".


 Some people have protested that I have "trivialized" Linux by using
 "linux", but I am perplexed why that's ok for gcc but not for D.


 Strawman.


 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).


 You're really stretching to say those aren't "sane" names. They're just
 names, they're not even intended to be identifiers. To make identifiers
 *for* them, removing the illegal chars (and using a non-schizophrenic
 casing
 scheme) is an obvious and non-problematic solution. Picking *ONE* of
 them to
 be lowercased instead of upper camel cased like the rest (or any other
 inconsistent casing) isn't merely "not sane", it's also completely
 unnecessary.


 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.


 Adding "Linux" as a preferred alternative to "linux" will not break large
 swaths of code.


 Yes, this would be a good idea. This approach could deprecate 'linux' in
 favor of 'Linux' as 'darwin' was deprecated in favor of 'OSX'.

 - Alex


I propose: https://github.com/D-Programming-Language/dmd/pull/501

- Alex
Nov 07 2011
parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Mon, 7 Nov 2011, Alex R?nne Petersen wrote:

 On 07-11-2011 14:59, Alex R?nne Petersen wrote:

 On 07-11-2011 14:20, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com> wrote in message
 news:j9784p$24tu$1 digitalmars.com...

 
 Based on my research:
 
 _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s,
 Windows 2000
 _WIN64 Windows for AMD64
 linux Linux
 __APPLE__ Mac OSX
 __FreeBSD__ FreeBSD
 __OpenBSD__ OpenBSD
 __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are
 necessary)
 
 Hence FreeBSD rather than freebsd or Freebsd. The underscores just
 looked
 awful :-) and are unnecessary for D since the version tags are in a
 separate namespace.
 
 Had to come up with one for Solaris.
 
 APPLE is hopelessly generic, considering Apple has produced many
 operating
 systems.
 
 __WINDOWS__ is not what DMC uses. See
 
 http://www.digitalmars.com/ctg/predefined.html
 


 
 You're completely contradicting your claim here of having used the gcc
 idents. Obviously you changed the idents, and you had a reason for
 each one.
 There's pretty damn good reason for changing "linux" too.
 
 At least Phobos is finally ditching the absolutely rediculous
 philosophy of
 "always use naming conventions from random other places, and don't
 ever even
 think about being internally-consistent".
 

 Some people have protested that I have "trivialized" Linux by using
 "linux", but I am perplexed why that's ok for gcc but not for D.
 


 
 Strawman.
 

 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).


 
 You're really stretching to say those aren't "sane" names. They're just
 names, they're not even intended to be identifiers. To make identifiers
 *for* them, removing the illegal chars (and using a non-schizophrenic
 casing
 scheme) is an obvious and non-problematic solution. Picking *ONE* of
 them to
 be lowercased instead of upper camel cased like the rest (or any other
 inconsistent casing) isn't merely "not sane", it's also completely
 unnecessary.
 

 
 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.


 
 Adding "Linux" as a preferred alternative to "linux" will not break large
 swaths of code.
 
 


 
 Yes, this would be a good idea. This approach could deprecate 'linux' in
 favor of 'Linux' as 'darwin' was deprecated in favor of 'OSX'.
 
 - Alex


 
 I propose: https://github.com/D-Programming-Language/dmd/pull/501
 
 - Alex


If any change is to be made, and I'm not sure it's a good idea to change 
anything at all here, I'd go with all lower case for all of them.
Nov 07 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2011 2:29 PM, Brad Roberts wrote:

 If any change is to be made, and I'm not sure it's a good idea to change
 anything at all here, I'd go with all lower case for all of them.


I don't see any gain to changing the existing identifiers. It's all
bikeshedding 
with the illusion of progress, yet making arbitrary amounts of work for others 
as they have to go edit their code. We've got much more important things that 
need doing.
Nov 07 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, November 07, 2011 17:04 Walter Bright wrote:

 On 11/7/2011 2:29 PM, Brad Roberts wrote:

 If any change is to be made, and I'm not sure it's a good idea to change
 anything at all here, I'd go with all lower case for all of them.


 
 I don't see any gain to changing the existing identifiers. It's all
 bikeshedding with the illusion of progress, yet making arbitrary amounts
 of work for others as they have to go edit their code. We've got much more
 important things that need doing.


I could see an argument for adding new version identifiers for one or two 
(leaving in the old ones for backwards compatability) of them if it made them 
all consistent, but outright changing any of them would break too much code, 
and changing most or all of them would _definitely_ break too much code. Yes, 
I'd prefer that linux be Linux, but I'm not sure that it's a good idea to have 
both Linux and linux work, and I definitely agree that changing any of those 
identifiers at this point would be too disruptive. So, while I think that the 
current situation is less than ideal, I think that we're pretty much stuck at 
this point.

- Jonathan M Davis
Nov 07 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
There is always one backwards compatible solution:

We could make version identifiers case insensitive.

It's a change from everywhere else in the language, but...

There is no 'correct' casing for os/architecture etc
windows vs Windows, linux vs Linux, x86 vs X86 are meaningless distinctions.

Invalid identifiers are _silently_ accepted.
eg.
version(Linux) {}
Would anybody ever _actually_ mean Linux here?

Because it works on a is/is not defined basis, this is one case where case 
sensitivity harms usability.  You never get an error for messing up the 
casing, unless you explicitly add a static assert in an else clause.

Does anybody really define both 'MyVersion' and 'myVersion' and expect them 
to do different things?

I think the inconsistency and the small addition to the spec are worth it to 
have the compiler silently and automatically do the right thing, and remove 
the impact of some incredibly inconsistent and arbirtary casing choices.
Nov 08 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 09-11-2011 02:29, Daniel Murphy wrote:

 There is always one backwards compatible solution:

 We could make version identifiers case insensitive.


That's not backwards-compatible. What if someone out there is really 
using Foo and fOO for two different things? I know this sounds 
far-fetched, but the possibility is there.


 It's a change from everywhere else in the language, but...

 There is no 'correct' casing for os/architecture etc
 windows vs Windows, linux vs Linux, x86 vs X86 are meaningless distinctions.


It's proper spelling of the titles of the architectures/OSs. I don't see 
how this is not correct.


 Invalid identifiers are _silently_ accepted.
 eg.
 version(Linux) {}
 Would anybody ever _actually_ mean Linux here?


Maybe... they could have:

version (linux) { version (Linux); }

to fix the inconsistency that is in place now. ;)


 Because it works on a is/is not defined basis, this is one case where case
 sensitivity harms usability.  You never get an error for messing up the
 casing, unless you explicitly add a static assert in an else clause.


Very true. But you're supposed to do that anyway, as Walter pointed out 
in a post to the druntime mailing list, because it aids portability.


 Does anybody really define both 'MyVersion' and 'myVersion' and expect them
 to do different things?

 I think the inconsistency and the small addition to the spec are worth it to
 have the compiler silently and automatically do the right thing, and remove
 the impact of some incredibly inconsistent and arbirtary casing choices.


In general, I agree, but this would be a breaking change no matter how 
you look at it. I'm not sure if that's a good idea.

- Alex
Nov 09 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:j9dviv$1jbd$4 digitalmars.com...

...

 In general, I agree, but this would be a breaking change no matter how you 
 look at it. I'm not sure if that's a good idea.

 - Alex


Thanks for the comments.  I expect this change would fix many, many more 
bugs than it causes.  But, as it is a breaking change (very slightly), and a 
special case, I doubt this will ever happen unless Walter loves the idea. 
Walter?
Nov 09 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2011 6:46 AM, Daniel Murphy wrote:

 But, as it is a breaking change (very slightly), and a
 special case, I doubt this will ever happen unless Walter loves the idea.
 Walter?


Sorry, I don't love the idea. I dislike it for its inconsistency with the rest 
of the language. The trend in programming languages and operating systems has, 
for a long time, been towards case sensitivity.

BTW, the correct way to write version sensitive code is:

version (linux)
{
    ...
}
else version (OSX)
{
    ...
}
else
    static assert(0, "unsupported OS version");


Otherwise, it's miserable to find and tweak all the version sensitive code in 
your codebase. Here's a WRONG WRONG WRONG way:

version (linux)
{
     ...
}
else /* Windows */
{
     ...
}

Looks stupid, but I tend to often see stuff like this in C, C++ and D source 
code. Even in my own. This is also why there's no ! for versions:

version (!linux)
{
     ...
}

Aaaaggghhhh. I'm pretty fed up with seeing that crap in C code. And if you see 
any of it in dmd or phobos sources, please file a bugzilla report! Show no
mercy.
Nov 09 2011
next sibling parent reply kennytm <kennytm gmail.com> writes:
Walter Bright <newshound2 digitalmars.com> wrote:

 On 11/9/2011 6:46 AM, Daniel Murphy wrote:

 But, as it is a breaking change (very slightly), and a
 special case, I doubt this will ever happen unless Walter loves the idea.
 Walter?


 
 Sorry, I don't love the idea. I dislike it for its inconsistency with the
 rest of the language. The trend in programming languages and operating
 systems has, for a long time, been towards case sensitivity.
 
 BTW, the correct way to write version sensitive code is:
 
 version (linux)
 {
    ...
 }
 else version (OSX)
 {
    ...
 }
 else
    static assert(0, "unsupported OS version");
 
 
 Otherwise, it's miserable to find and tweak all the version sensitive
 code in your codebase. Here's a WRONG WRONG WRONG way:
 
 version (linux)
 {
     ...
 }
 else /* Windows */
 {
     ...
 }
 
 Looks stupid, but I tend to often see stuff like this in C, C++ and D
 source code. Even in my own. This is also why there's no ! for versions:
 
 version (!linux)
 {
     ...
 }
 
 Aaaaggghhhh. I'm pretty fed up with seeing that crap in C code. And if
 you see any of it in dmd or phobos sources, please file a bugzilla report!
Show no mercy.


Perhaps DMD should generate a warning if a version of platforms does not
have an else clause or that version's else clause's content is not another
version statement or a static assert.
Nov 09 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 04:07:43 kennytm wrote:

 Perhaps DMD should generate a warning if a version of platforms does not
 have an else clause or that version's else clause's content is not another
 version statement or a static assert.


Well, that does get a bit fuzzy. For instance, rather than duplicating that 
else clause all over the place in std.file, only the first static if-else
clause 
has the else with the static assert in it. All of the others just have the 
branches that work and don't have an else clause. If we were to require that 
there be an else like that, then std.file wouldn't compile. And while it 
wouldn't be all that bad to have to put an else on all of those static-ifs, it 
_would_ result in unnecessary code duplication.

- Jonathan M Davis
Nov 09 2011
parent reply kennytm <kennytm gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Thursday, November 10, 2011 04:07:43 kennytm wrote:

 Perhaps DMD should generate a warning if a version of platforms does not
 have an else clause or that version's else clause's content is not another
 version statement or a static assert.


 
 Well, that does get a bit fuzzy. For instance, rather than duplicating that 
 else clause all over the place in std.file, only the first static if-else
clause 
 has the else with the static assert in it. All of the others just have the 
 branches that work and don't have an else clause. If we were to require that 
 there be an else like that, then std.file wouldn't compile. And while it 
 wouldn't be all that bad to have to put an else on all of those static-ifs, it 
 _would_ result in unnecessary code duplication.
 
 - Jonathan M Davis


I said version(Platform)s, not static if.
Nov 09 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 05:08:03 kennytm wrote:

 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Thursday, November 10, 2011 04:07:43 kennytm wrote:

 Perhaps DMD should generate a warning if a version of platforms does
 not
 have an else clause or that version's else clause's content is not
 another version statement or a static assert.


 
 Well, that does get a bit fuzzy. For instance, rather than duplicating
 that else clause all over the place in std.file, only the first static
 if-else clause has the else with the static assert in it. All of the
 others just have the branches that work and don't have an else clause.
 If we were to require that there be an else like that, then std.file
 wouldn't compile. And while it wouldn't be all that bad to have to put
 an else on all of those static-ifs, it _would_ result in unnecessary
 code duplication.
 
 - Jonathan M Davis


 
 I said version(Platform)s, not static if.


LOL. Yes. And I meant version(Platform). I obviously had my wires crossed when 
I wrote that. std.file uses

version(Posix)
{}
else version(Windows)
{}

without an else block, except for the first one in the file which _does_ have
an 
else which has a static assert(0) in it. Requiring that all such version 
blocks had elses would invalidate that approach.

- Jonathan M Davis
Nov 09 2011
parent reply kennytm <kennytm gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Thursday, November 10, 2011 05:08:03 kennytm wrote:

 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Thursday, November 10, 2011 04:07:43 kennytm wrote:

 Perhaps DMD should generate a warning if a version of platforms does
 not
 have an else clause or that version's else clause's content is not
 another version statement or a static assert.


 
 Well, that does get a bit fuzzy. For instance, rather than duplicating
 that else clause all over the place in std.file, only the first static
 if-else clause has the else with the static assert in it. All of the
 others just have the branches that work and don't have an else clause.
 If we were to require that there be an else like that, then std.file
 wouldn't compile. And while it wouldn't be all that bad to have to put
 an else on all of those static-ifs, it _would_ result in unnecessary
 code duplication.
 
 - Jonathan M Davis


 
 I said version(Platform)s, not static if.


 
 LOL. Yes. And I meant version(Platform). I obviously had my wires crossed when 
 I wrote that. std.file uses
 
 version(Posix)
 {}
 else version(Windows)
 {}
 
 without an else block, except for the first one in the file which _does_ have
an 
 else which has a static assert(0) in it. Requiring that all such version 
 blocks had elses would invalidate that approach.
 
 - Jonathan M Davis


Yes, but imagine there's a non-POSIX non-Windows platform (e.g. an embedded
system), and we make stdio to support it. After we add a
version(NewPlatform) branch to the one containing the static assert, the
compiler can no longer help us  to know some version statement in the
middle may have missed the NewPlatform. 

This is a contrived example, and I agree it would often be too strict, so I
think there should be individual warning switches.
Nov 10 2011
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 13:10 kennytm wrote:

 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Thursday, November 10, 2011 05:08:03 kennytm wrote:

 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Thursday, November 10, 2011 04:07:43 kennytm wrote:

 Perhaps DMD should generate a warning if a version of platforms does
 not
 have an else clause or that version's else clause's content is not
 another version statement or a static assert.


 
 Well, that does get a bit fuzzy. For instance, rather than duplicating
 that else clause all over the place in std.file, only the first static
 if-else clause has the else with the static assert in it. All of the
 others just have the branches that work and don't have an else clause.
 If we were to require that there be an else like that, then std.file
 wouldn't compile. And while it wouldn't be all that bad to have to put
 an else on all of those static-ifs, it _would_ result in unnecessary
 code duplication.
 
 - Jonathan M Davis


 
 I said version(Platform)s, not static if.


 
 LOL. Yes. And I meant version(Platform). I obviously had my wires crossed
 when I wrote that. std.file uses
 
 version(Posix)
 {}
 else version(Windows)
 {}
 
 without an else block, except for the first one in the file which _does_
 have an else which has a static assert(0) in it. Requiring that all such
 version blocks had elses would invalidate that approach.
 
 - Jonathan M Davis


 
 Yes, but imagine there's a non-POSIX non-Windows platform (e.g. an embedded
 system), and we make stdio to support it. After we add a
 version(NewPlatform) branch to the one containing the static assert, the
 compiler can no longer help us to know some version statement in the
 middle may have missed the NewPlatform.
 
 This is a contrived example, and I agree it would often be too strict, so I
 think there should be individual warning switches.


I'm not completely against the idea. I'm just pointing out that it's more 
restrictive that way and potentially messier in code with a lot of version 
statements. There's no question that the vast majority of people aren't going 
to have an else clause with a static assert when versioning OSes. And it 
wouldn't surprise me if something like 99% of the people who do do it do it 
because Walter pointed out the need to them or someone else who Walter had 
pointed it out to pointed it out to them.

- Jonathan M Davis
Nov 10 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:j9f442$k3p$1 digitalmars.com...

 On 11/9/2011 6:46 AM, Daniel Murphy wrote:

 But, as it is a breaking change (very slightly), and a
 special case, I doubt this will ever happen unless Walter loves the idea.
 Walter?


 Sorry, I don't love the idea. I dislike it for its inconsistency with the 
 rest of the language. The trend in programming languages and operating 
 systems has, for a long time, been towards case sensitivity.

 BTW, the correct way to write version sensitive code is:

 version (linux)
 {
    ...
 }
 else version (OSX)
 {
    ...
 }
 else
    static assert(0, "unsupported OS version");


I don't think you're going to get most people to go through the bother of 
doing this, do you? I agree this is the right thing to do, *now that I see 
it pointed out*, but even at that it's going to remain tempting not to 
bother (and easy to forget).

Maybe there should be an error when no part of a version...else chain gets 
used? That way the "static assert(0);" becomes implicit, and people aren't 
going to fuck it up by forgetting, not knowing to do it, or feeling too lazy 
to bother.
Nov 10 2011
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 05-11-2011 21:48, Iain Buclaw wrote:

 I have had a recent pull request regarding the updating of some of GDC's OS
 and Arch version identifiers.

 https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version

 Such changes include, aix ->  AIX; ALPHA ->  Alpha;  and a few more.


 While I welcome any change suggestions, I would love to hear the opinion of D
 users on the proposed change.


 Regards
 Iain


I have sent a pull request to update d-p-l.org with the new version 
identifiers supported in GDC, LDC, and SDC: 
https://github.com/D-Programming-Language/d-programming-language.org/pull/32

Can I bug someone to review this?

- Alex
Nov 11 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/11 6:44 AM, Alex Rønne Petersen wrote:

 On 05-11-2011 21:48, Iain Buclaw wrote:

 I have had a recent pull request regarding the updating of some of
 GDC's OS
 and Arch version identifiers.

 https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version


 Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more.


 While I welcome any change suggestions, I would love to hear the
 opinion of D
 users on the proposed change.


 Regards
 Iain


 I have sent a pull request to update d-p-l.org with the new version
 identifiers supported in GDC, LDC, and SDC:
 https://github.com/D-Programming-Language/d-programming-language.org/pull/32


 Can I bug someone to review this?

 - Alex


Done. Thanks!

Andrei
Nov 11 2011
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 11-11-2011 18:15, Andrei Alexandrescu wrote:

 On 11/11/11 6:44 AM, Alex Rønne Petersen wrote:

 On 05-11-2011 21:48, Iain Buclaw wrote:

 I have had a recent pull request regarding the updating of some of
 GDC's OS
 and Arch version identifiers.

 https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version



 Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more.


 While I welcome any change suggestions, I would love to hear the
 opinion of D
 users on the proposed change.


 Regards
 Iain


 I have sent a pull request to update d-p-l.org with the new version
 identifiers supported in GDC, LDC, and SDC:
 https://github.com/D-Programming-Language/d-programming-language.org/pull/32



 Can I bug someone to review this?

 - Alex


 Done. Thanks!

 Andrei


Amendment: 
https://github.com/D-Programming-Language/d-programming-language.org/pull/36

I think this is one of those funny cases where copy/pasting would have 
been a better idea. :)

- Alex
Nov 14 2011
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 15-11-2011 02:15, Alex Rønne Petersen wrote:

 On 11-11-2011 18:15, Andrei Alexandrescu wrote:

 On 11/11/11 6:44 AM, Alex Rønne Petersen wrote:

 On 05-11-2011 21:48, Iain Buclaw wrote:

 I have had a recent pull request regarding the updating of some of
 GDC's OS
 and Arch version identifiers.

 https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version




 Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more.


 While I welcome any change suggestions, I would love to hear the
 opinion of D
 users on the proposed change.


 Regards
 Iain


 I have sent a pull request to update d-p-l.org with the new version
 identifiers supported in GDC, LDC, and SDC:
 https://github.com/D-Programming-Language/d-programming-language.org/pull/32




 Can I bug someone to review this?

 - Alex


 Done. Thanks!

 Andrei


 Amendment:
 https://github.com/D-Programming-Language/d-programming-language.org/pull/36


 I think this is one of those funny cases where copy/pasting would have
 been a better idea. :)

 - Alex


By the way, I just noticed that on 
http://www.d-programming-language.org/version.html the 
D_InlineAsm_X86_64 entry is being hyphenated. I don't think this is a 
good thing, considering it *is* an identifier. Could we get rid of that 
somehow?

- Alex
Nov 14 2011