www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The future of std.compiler

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
Hi,

I recently sent some pull requests to move std.compiler into 
core.compiler. Sean Kelly raised the issue that druntime is very 
compiler-specific (i.e. GDC and LDC both have their own druntime forks). 
Given this, having it in druntime probably doesn't make a whole lot of 
sense.

So, the question is, does the module serve any purpose in Phobos? The 
documentation on version identifiers was updated recently with version 
identifiers for the various compilers, so detecting different compilers 
is already trivial. Having encapsulation around version identifiers in 
Phobos is arguably rather pointless. On the other hand, the module also 
provides compiler name and version, which I do not believe are defined 
in all compilers (please correct me if I'm wrong!).

What does everyone think? Should we keep this module around or just 
deprecate it?

- Alex
Nov 20 2011
parent reply torhu <no spam.invalid> writes:
On 20.11.2011 20:44, Alex Rnne Petersen wrote:
 Hi,

 I recently sent some pull requests to move std.compiler into
 core.compiler. Sean Kelly raised the issue that druntime is very
 compiler-specific (i.e. GDC and LDC both have their own druntime forks).
 Given this, having it in druntime probably doesn't make a whole lot of
 sense.

 So, the question is, does the module serve any purpose in Phobos? The
 documentation on version identifiers was updated recently with version
 identifiers for the various compilers, so detecting different compilers
 is already trivial. Having encapsulation around version identifiers in
 Phobos is arguably rather pointless. On the other hand, the module also
 provides compiler name and version, which I do not believe are defined
 in all compilers (please correct me if I'm wrong!).

 What does everyone think? Should we keep this module around or just
 deprecate it?

IIRC, that module was added before __VENDOR__ and __VERSION__ were added to DMD. If it wasn't for that, I suppose it wouldn't even exist.
Nov 20 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 20/11/2011 22:58, torhu wrote:
 On 20.11.2011 20:44, Alex Rnne Petersen wrote:

 What does everyone think? Should we keep this module around or just
 deprecate it?

IIRC, that module was added before __VENDOR__ and __VERSION__ were added to DMD. If it wasn't for that, I suppose it wouldn't even exist.

Identifiers beginning with __ are implementation-specific. std.compiler, OTOH, continues to exist in order to provide _standardised_ access to information about the compiler. Stewart.
Nov 29 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 11/29/11 9:17 PM, Stewart Gordon wrote:
 Identifiers beginning with __ are implementation-specific. std.compiler,
 OTOH, continues to exist in order to provide _standardised_ access to
 information about the compiler.

Not in this case – actually, all special tokens defined by the language are enclosed in double underscores: http://d-programming-language.org/lex.html#specialtokens. David
Nov 29 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 29/11/2011 20:31, David Nadlinger wrote:
 On 11/29/11 9:17 PM, Stewart Gordon wrote:
 Identifiers beginning with __ are implementation-specific. std.compiler,
 OTOH, continues to exist in order to provide _standardised_ access to
 information about the compiler.

Not in this case – actually, all special tokens defined by the language are enclosed in double underscores: http://d-programming-language.org/lex.html#specialtokens.

__FILE__ and __LINE__ aren't in that list - what gives? But it seems the relationship between __VERSION__ values and x.y version numbers isn't defined - so std.compiler remains the only way of accessing the latter. Stewart.
Nov 29 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-29 23:57, Stewart Gordon wrote:
 On 29/11/2011 20:31, David Nadlinger wrote:
 On 11/29/11 9:17 PM, Stewart Gordon wrote:
 Identifiers beginning with __ are implementation-specific. std.compiler,
 OTOH, continues to exist in order to provide _standardised_ access to
 information about the compiler.

Not in this case – actually, all special tokens defined by the language are enclosed in double underscores: http://d-programming-language.org/lex.html#specialtokens.

__FILE__ and __LINE__ aren't in that list - what gives? But it seems the relationship between __VERSION__ values and x.y version numbers isn't defined - so std.compiler remains the only way of accessing the latter. Stewart.

They're in the list above, in the list of keywords. -- /Jacob Carlborg
Nov 29 2011