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
next sibling 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 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
next sibling parent =?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
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 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 next 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
next sibling 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 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
prev sibling parent 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
prev sibling parent 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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--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?

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

 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

 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

--001485ec112698f20204b120c415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I&#39;ve been running into this problem on consoles.<div>I&#39;d vote for c= reating a standard, only creating new identifiers according to that standar= d, and also adding standardised versions of existing identifiers (leaving a= lso the ones don&#39;t conform, possibly remove them in D3)<br> <br>The __APPLE__ one is a problem, how to identify=C2=A0iOS? OS8/9?</div><= div><br></div><div>I&#39;ve been tinkering with PSP... what about Android, = PS3, XBox(/360), etc...</div><div>Some of these platforms exist on multiple= architectures... how to distinguish the architecture from the platform? St= andardisation of arch names?</div> <div><br><div class=3D"gmail_quote">On 7 November 2011 03:33, Jonathan M Da= vis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisPro= g gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On Sunday, November 06, 2011 16:17:59 Walter Bright wrote= :<br> &gt; And finally, there is no such thing as a &quot;sane&quot; version iden= tifier scheme.<br> &gt; For one thing, OS vendors do not pick sane names. OS/2 is not an<br> &gt; identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors p= ick<br> &gt; any sane identifiers for their own systems (look at what Sun did).<br> &gt;<br> &gt; Even if someone comes up with a naming scheme for D that most agree is= sane,<br> &gt; intuitive, and attractive, switching to it would again silently break = a<br> &gt; large swath of existing D code. D cannot advance by constantly breakin= g<br> &gt; things.<br> <br> </div>I think that what it comes down to is that most D programmers are loo= king for<br> consistency and don&#39;t care what C is doing with its version identifiers= . You<br> have to look up what they are regardless, since even if you know the C<br> identifiers and you know that D is trying to follow them, there&#39;s still= no<br> guarantee that they&#39;re the same. It may not be worth making breaking ch= anges<br> (e.g. changing linux to Linux) at this point, but at minimum, I&#39;d argue= that<br> new version identifiers should be more consistent. And I believe that some = have<br> argued in the pas that we should just add Linux to make it consistent, but<= br> leave linux to avoid code breakage (which has the upside of increasing<br> consistency but the downside of creating two version identifiers for the sa= me<br> thing).<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> - Jonathan M Davis<br> </font></span></blockquote></div><br></div> --001485ec112698f20204b120c415--
Nov 07 2011
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001485ec1126432c7904b122e49b
Content-Type: text/plain; charset=UTF-8

 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] --001485ec1126432c7904b122e49b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Both Mac OS X an= d iOS builds on the same foundation.</blockquote><div><br></div><div>True-i= sh, but they&#39;re not even slightly the same from a developer perspective= . People often make that mistake, where technologies are similar, but negle= ct the fact that you have to do fundamentally different things on the devic= es.</div> <div>They need to be distinguished. If darwin is defined, then it ALSO need= s a OSX/iOS for disambiguation in addition.</div><div>=C2=A0</div><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex;"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve been tinkering wi= th PSP... what about Android, PS3, XBox(/360), etc...<br> Some of these platforms exist on multiple architectures... how to<br> distinguish the architecture from the platform? Standardisation of arch<br> names?<br> </blockquote> <br></div> There are version identifiers for different architectures as well, e.g. X86= , X86_64 and so on.</blockquote><div><br></div><div>Yes, but they need to b= e declared standard, and listed somewhere. If they&#39;re not reliable, the= n you&#39;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 de= fines into useful macros for your app.</div> <div><br></div><div>For any platform/architecture, there should ALWAYS be a= vailable at least identifiers for PLATFORM, OS, and ARCHITECTURE.</div><div=
An identifier for TOOLCHAIN is often useful too, since different toolchain=

rticular... GCC, SN, Codewarrior, proprietary compilers; all target exactly= the same thing, but require some toolchain specific code.</div> <div><br></div><div>Basically I think if those three (I&#39;d argue for 4) = things aren&#39;t present, standardised, and dependable, there will always = eventually be the mess we all love in the top of C header files.</div><div> <br></div><div>For instance, the OSX example above, I&#39;d suggest somethi= ng like:</div><div>=C2=A0PLATFORM =3D darwin</div><div>=C2=A0OS =3D OSX/iOS= </div><div>=C2=A0ARCHITECTURE =3D X86/PPC/ARM</div><div>=C2=A0TOOLCHAIN =3D= [whatever]</div></div> --001485ec1126432c7904b122e49b--
Nov 07 2011
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0016e64135e8f14afe04b1235e88
Content-Type: text/plain; charset=UTF-8

 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. --0016e64135e8f14afe04b1235e88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I&#39;m not sure= I see the idea in having a platform value separate from an OS value. Other= wise I agree; OS, architecture, and toolchain should always be identifiable= .</blockquote> <div><br></div><div>Platform identifies some sort of common foundation; as = dawrin is to OSX/iOS</div><div><br></div><div>Linux running on an xbox is s= till running on an xbox, and definitely distinct from linux running on any = old pc.</div> </div> --0016e64135e8f14afe04b1235e88--
Nov 07 2011
prev sibling parent Manu <turkeyman gmail.com> writes:
--00163646dc2ebeeb8904b12cf075
Content-Type: text/plain; charset=UTF-8

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

 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 :/ --00163646dc2ebeeb8904b12cf075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 November 2011 00:33, Iain Buclaw <span dir= =3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuclaw ubuntu.com</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex;"> =3D=3D Quote from Manu (<a href=3D"mailto:turkeyman gmail.com">turkeyman gm= ail.com</a>)&#39;s article<br> &gt; --001485ec112698f20204b120c415<br> &gt; Content-Type: text/plain; charset=3DUTF-8<br> <div class=3D"im">&gt; I&#39;ve been running into this problem on consoles.= <br> &gt; I&#39;d vote for creating a standard, only creating new identifiers ac= cording<br> &gt; to that standard, and also adding standardised versions of existing<br=

them in<br> &gt; D3)<br> &gt; The __APPLE__ one is a problem, how to identify iOS? OS8/9?<br> </div><div class=3D"im">&gt; I&#39;ve been tinkering with PSP... what about= Android, PS3, XBox(/360), etc...<br> &gt; Some of these platforms exist on multiple architectures... how to<br> &gt; distinguish the architecture from the platform? Standardisation of arc= h<br> &gt; names?<br> <br> </div>I don&#39;t see any real need to have identifiers for console platfor= ms built into<br> the compiler. =C2=A0As you&#39;d pretty much always would be using a homebr= ew cross-<br> compiler, and can simply pass -version=3DPSP on the command-line in the bui= ld<br> command.<br> </blockquote><div><br></div><div>... I guess. But I reckon=C2=A0it&#39;s a = bit of a pain in the arse to remember to do that everywhere (and edit scrip= ts all over the place when cross compiling).</div><div>I don&#39;t really s= ee why a platform specific toolchain wouldn&#39;t know what it is, and defi= ne its self as such.</div> <div><br></div><div>Not to mention, if you leave it up to the user to expec= t some arbitrary version identifier passed into their code, you&#39;ll neve= r find a standard accepted by all code for a platform... it&#39;ll just be = a total mess like C is now.</div> <div>I say it should be proactively selected to encourage standardisation o= n one, and it should be asserted by the compiler automatically. 10 years of= arguing with different compilers and libs for the same platforms disagreei= ng on how to identify the thing has taught me that much :/</div> </div> --00163646dc2ebeeb8904b12cf075--
Nov 07 2011
prev sibling next sibling 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 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
prev sibling next sibling 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
next sibling parent 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
prev sibling 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
next sibling parent 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
prev sibling 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