A)
How to query for compiler flags, eg whether or not "noboundscheck" was set?

B)
Why aren't we using version=noboundscheck (+ friends) instead of
-noboundscheck?

C)
similar to version(assert) which IIRC was introduced later, could we
introduce version(noboundscheck) (+ friends) ?

On 06/03/2013 03:11 PM, Timothee Cour wrote:

> A)
> How to query for compiler flags, eg whether or not "noboundscheck" was set?

version D_NoBoundsChecks:

  http://dlang.org/version.html

> B)
> Why aren't we using version=noboundscheck (+ friends) instead of
> -noboundscheck?

Because the runtime is not written in D. :) However, it should be easy to translate version=noboundscheck to -noboundscheck.

> C)
> similar to version(assert) which IIRC was introduced later, could we
> introduce version(noboundscheck) (+ friends) ?

It is there! :) (I haven't test it though.)

Ali

Thanks, D_NoBoundsChecks indeed works.


On Mon, Jun 3, 2013 at 3:19 PM, Ali Çehreli <acehreli@yahoo.com> wrote:

> On 06/03/2013 03:11 PM, Timothee Cour wrote:
>
> > A)
> > How to query for compiler flags, eg whether or not "noboundscheck" was
> set?
>
> version D_NoBoundsChecks:
>
>   http://dlang.org/version.html
>
>
> > B)
> > Why aren't we using version=noboundscheck (+ friends) instead of
> > -noboundscheck?
>
> Because the runtime is not written in D. :) However, it should be easy to translate version=noboundscheck to -noboundscheck.


That seems like an unimportant technicality, isn't it?
Couldn't we define version=noboundscheck when noboundscheck is used?
Why use version(D_NoBoundsChecks) instead of version(noboundscheck) ?




> > C)
> > similar to version(assert) which IIRC was introduced later, could we
> > introduce version(noboundscheck) (+ friends) ?
>
> It is there! :) (I haven't test it though.)
>
> Ali
>
>

On Monday, June 03, 2013 15:19:22 Ali Çehreli wrote:
>  > B)
>  > Why aren't we using version=noboundscheck (+ friends) instead of
>  > -noboundscheck?
> 
> Because the runtime is not written in D. :) However, it should be easy to translate version=noboundscheck to -noboundscheck.

The runtime _is_ written in D. It's the compiler that isn't, and the compiler itself generates different code based on noboundscheck. But the version D_NoBoundsChecks is new (it might even be new with this release - certainly at most it's a release or two old). We've had the noboundscheck flag far, far longer than that. The same goes for the assert version. It was only added very recently, but we've always had assertions.

Also, if you'll notice, version is _never_ used to control anything that the compiler itself does. It affects code that you write, because of what you've done with version blocks, but the compiler itself doesn't change what it does due to the version flag save for which version blocks do or don't get compiled in. Compiler flags are used to control the compiler, not version identifiers. All of the standard identifiers are for user code to be able to react to what version of the compiler you're using, what system you're on, and what compilation flags you used. The only ones that get set by the user are user- defined versions.

- Jonathan M Davis

Again, this seems like an unimportant technicality.
For user code, whether the logic is handled in the compiler or druntime
shouldn't make a difference, so why not have version(D_NoBoundsChecks)
instead of version(noboundscheck). It makes it more discoverable, and more
consistent with the rest (eg: dmd -debug will imply version(debug) is on).

On Mon, Jun 3, 2013 at 4:29 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Monday, June 03, 2013 15:19:22 Ali Çehreli wrote:
> >  > B)
> >  > Why aren't we using version=noboundscheck (+ friends) instead of
> >  > -noboundscheck?
> >
> > Because the runtime is not written in D. :) However, it should be easy to translate version=noboundscheck to -noboundscheck.
>
> The runtime _is_ written in D. It's the compiler that isn't, and the
> compiler
> itself generates different code based on noboundscheck. But the version
> D_NoBoundsChecks is new (it might even be new with this release -
> certainly at
> most it's a release or two old). We've had the noboundscheck flag far, far
> longer than that. The same goes for the assert version. It was only added
> very
> recently, but we've always had assertions.
>
> Also, if you'll notice, version is _never_ used to control anything that
> the
> compiler itself does. It affects code that you write, because of what
> you've
> done with version blocks, but the compiler itself doesn't change what it
> does
> due to the version flag save for which version blocks do or don't get
> compiled
> in. Compiler flags are used to control the compiler, not version
> identifiers.
> All of the standard identifiers are for user code to be able to react to
> what
> version of the compiler you're using, what system you're on, and what
> compilation flags you used. The only ones that get set by the user are
> user-
> defined versions.
>
> - Jonathan M Davis
>

I meant 'why not have version(noboundscheck) instead of
version(D_NoBoundsChecks)'
of course.

On Mon, Jun 3, 2013 at 4:48 PM, Timothee Cour <thelastmammoth@gmail.com>wrote:

> Again, this seems like an unimportant technicality.
> For user code, whether the logic is handled in the compiler or druntime
> shouldn't make a difference, so why not have version(D_NoBoundsChecks)
> instead of version(noboundscheck). It makes it more discoverable, and more
> consistent with the rest (eg: dmd -debug will imply version(debug) is on).
>
>
> On Mon, Jun 3, 2013 at 4:29 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
>
>> On Monday, June 03, 2013 15:19:22 Ali Çehreli wrote:
>> >  > B)
>> >  > Why aren't we using version=noboundscheck (+ friends) instead of
>> >  > -noboundscheck?
>> >
>> > Because the runtime is not written in D. :) However, it should be easy to translate version=noboundscheck to -noboundscheck.
>>
>> The runtime _is_ written in D. It's the compiler that isn't, and the
>> compiler
>> itself generates different code based on noboundscheck. But the version
>> D_NoBoundsChecks is new (it might even be new with this release -
>> certainly at
>> most it's a release or two old). We've had the noboundscheck flag far, far
>> longer than that. The same goes for the assert version. It was only added
>> very
>> recently, but we've always had assertions.
>>
>> Also, if you'll notice, version is _never_ used to control anything that
>> the
>> compiler itself does. It affects code that you write, because of what
>> you've
>> done with version blocks, but the compiler itself doesn't change what it
>> does
>> due to the version flag save for which version blocks do or don't get
>> compiled
>> in. Compiler flags are used to control the compiler, not version
>> identifiers.
>> All of the standard identifiers are for user code to be able to react to
>> what
>> version of the compiler you're using, what system you're on, and what
>> compilation flags you used. The only ones that get set by the user are
>> user-
>> defined versions.
>>
>> - Jonathan M Davis
>>
>
>

On Monday, June 03, 2013 16:49:29 Timothee Cour wrote:
> I meant 'why not have version(noboundscheck) instead of
> version(D_NoBoundsChecks)'
> of course.

So, you're complaining about the name of the version identifier? I thought that you were complaining that we were using a flag instead a version identifier to turn on noboundscheck.

I don't know why that name was chosen or even who chose it. If you look at the list of official identifiers, you can see that it's pretty arbitrary as to what the exact naming scheme is. Not even the casing is consistent. So, I expect that D_NoBoundsCheck was chosen simply because whoever picked it thought that it best followed the generally naming scheme, or they just preferred that name. As it stands, there's really no hope of being able to figure out what any of the official version identifiers are without looking them up and memorizing them - including the spelling and whatever other naming quirks that particular identifier may have. And unfortunately, there's no way that that's going to be fixed at this point due to code breakage that it would cause.

You might be able to get D_NoBoundsChecks changed given how new it is, but I don't know.

- Jonathan M Davis

A)
whether the logic is done in compiler or druntime shouldn't matter to user,
so it'd be nice to use as uniform syntax as possible, ie:
dmd -version=noboundscheck should be supported (in addition to existing
-noboundscheck)
Implementation can then use that version flag to set compiler
flag -noboundscheck.

B)
noboundscheck can be used in library code as well for similar bounds
checking semantics: for example, checking index bounds inside a user
defined opIndex method. Hence distinguishing between compiler flag vs
version flag doesn't make that much sense.

C)
It was introduced here:
https://github.com/D-Programming-Language/dlang.org/commit/a4e2aa3ef7e4a6eec1c726ac9492221507cacfcf#version.dd
by @alexrp.

Since it wasn't in any change log, it's recent and makes sense, can we start a deprecation path to have D_NoBoundsChecks => noboundscheck ?


On Mon, Jun 3, 2013 at 5:46 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Monday, June 03, 2013 16:49:29 Timothee Cour wrote:
> > I meant 'why not have version(noboundscheck) instead of
> > version(D_NoBoundsChecks)'
> > of course.
>
> So, you're complaining about the name of the version identifier? I thought
> that
> you were complaining that we were using a flag instead a version
> identifier to
> turn on noboundscheck.
>
> I don't know why that name was chosen or even who chose it. If you look at
> the
> list of official identifiers, you can see that it's pretty arbitrary as to
> what
> the exact naming scheme is. Not even the casing is consistent. So, I expect
> that D_NoBoundsCheck was chosen simply because whoever picked it thought
> that
> it best followed the generally naming scheme, or they just preferred that
> name. As it stands, there's really no hope of being able to figure out
> what any
> of the official version identifiers are without looking them up and
> memorizing
> them - including the spelling and whatever other naming quirks that
> particular
> identifier may have. And unfortunately, there's no way that that's going
> to be
> fixed at this point due to code breakage that it would cause.
>
> You might be able to get D_NoBoundsChecks changed given how new it is, but
> I
> don't know.
>
> - Jonathan M Davis
>

On Monday, June 03, 2013 18:57:07 Timothee Cour wrote:
> A)
> whether the logic is done in compiler or druntime shouldn't matter to user,
> so it'd be nice to use as uniform syntax as possible, ie:
> dmd -version=noboundscheck should be supported (in addition to existing
> -noboundscheck)
> Implementation can then use that version flag to set compiler
> flag -noboundscheck.

I disagree. -version is for user-defined version identifiers, not official ones.

> B)
> noboundscheck can be used in library code as well for similar bounds
> checking semantics: for example, checking index bounds inside a user
> defined opIndex method. Hence distinguishing between compiler flag vs
> version flag doesn't make that much sense.

There isn't a need to disambiguate. If -noboundscheck is used, then D_NoBoundsCheck is defined. No one should ever be passing -version=D_NoBoundsCheck to dmd. It's exactly the same with versions such as linux or X86. It's the compiler that sets those.

> C)
> It was introduced here:
> https://github.com/D-Programming-Language/dlang.org/commit/a4e2aa3ef7e4a6eec
> 1c726ac9492221507cacfcf#version.dd by @alexrp.
> 
> Since it wasn't in any change log, it's recent and makes sense, can we start a deprecation path to have D_NoBoundsChecks => noboundscheck ?

That would be up to the compiler devs. I deal with Phobos and to some extent druntime but don't do any work on the compiler.

- Jonathan M Davis

By the way, what is the naming convention of predefined versions?  I am having a hard time trying to figure it out by myself from the docs (http://dlang.org/version.html#PredefinedVersions).

To me, it would make sense if all predefined versions started with "D_" or something similar to avoid conflicts with user versions.  Currently, the exceptions are vendor-related and architecture-related (a whole lot of them, actually) as well as the following:

unittest
assert
all
none

Now, "all" and "none" are clearly special.  But, really, what's the conceptual difference between "unittest", "assert" and "D_NoBoundsChecks" which results in using the different naming convention?

Ivan Kazmenko.