version(noboundscheck) + friends

[Timothee Cour]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20130603/9712af74/attachment.html>