On Tuesday, June 04, 2013 05:17:08 Ivan Kazmenko wrote:
> 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?

Sorry. There is no naming convention. It's completely arbitrary. They were added haphazardly over time, and AFAIK, there was never any real effort when adding them to make them consistent, or if there was, the conventions weren't followed consistently throughout, and the end result is that there really is no naming convention. And Walter didn't want to change any of them later, because that would break code (and potentially do so in silent and nasty ways). So, we're stuck with an incredibly inconsistent set of names.

- Jonathan M Davis

We really should aim to minimize the
wtfpm<http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/>
for
future users. I propose:
* support version(nocheckbounds) with same meaning as version(
D_NoBoundsChecks)
* list D_NoBoundsChecks as soft-deprecated. By soft-deprecated I mean list
it in http://dlang.org/deprecate.html but keep it for now, perhaps
indefinitely.


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

> On Tuesday, June 04, 2013 05:17:08 Ivan Kazmenko wrote:
> > 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?
>
> Sorry. There is no naming convention. It's completely arbitrary. They were
> added haphazardly over time, and AFAIK, there was never any real effort
> when
> adding them to make them consistent, or if there was, the conventions
> weren't
> followed consistently throughout, and the end result is that there really
> is
> no naming convention. And Walter didn't want to change any of them later,
> because that would break code (and potentially do so in silent and nasty
> ways). So, we're stuck with an incredibly inconsistent set of names.
>
> - Jonathan M Davis
>

On Monday, June 03, 2013 23:17:03 Timothee Cour wrote:
> We really should aim to minimize the
> wtfpm<http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wt
> fs-per-minute/> for
> future users. I propose:
> * support version(nocheckbounds) with same meaning as version(
> D_NoBoundsChecks)
> * list D_NoBoundsChecks as soft-deprecated. By soft-deprecated I mean list
> it in http://dlang.org/deprecate.html but keep it for now, perhaps
> indefinitely.

Feel free to make an enhancement request: http//d.puremagic.com/issues

And if you can track down which commit added D_NoBoundsChecks, it might even be easy to figure out how to implement it yourself and submit a pull request.

Given the fact that the entire list version identifiers is one big WTF, and we're not going to fix the general problem due to the code brekage that it would cause, I don't see much point in worrying about it, but feel free to try and get it changed.

- Jonathan M Davis

On Monday, 3 June 2013 at 22:19:23 UTC, Ali Çehreli wrote:
> On 06/03/2013 03:11 PM, Timothee Cour wrote:
> > Why aren't we using version=noboundscheck (+ friends) instead
> of
> > -noboundscheck?

Hijack: what about version(integeroverflow)

?

On Tuesday, June 04, 2013 09:14:28 eles wrote:
> On Monday, 3 June 2013 at 22:19:23 UTC, Ali Çehreli wrote:
> > On 06/03/2013 03:11 PM, Timothee Cour wrote:
> > > Why aren't we using version=noboundscheck (+ friends) instead
> > 
> > of
> > 
> > > -noboundscheck?
> 
> Hijack: what about version(integeroverflow)

Nothing in the language checks for integer overflow, and given the overhead that it would introduce, there's pretty much no way that it's ever going to be added. Walter has been against it every time that it's come up.

- Jonathan M Davis

On Tuesday, 4 June 2013 at 07:19:52 UTC, Jonathan M Davis wrote:
> On Tuesday, June 04, 2013 09:14:28 eles wrote:
>> On Monday, 3 June 2013 at 22:19:23 UTC, Ali Çehreli wrote:
>> > On 06/03/2013 03:11 PM, Timothee Cour wrote:
> Nothing in the language checks for integer overflow, and given the overhead
> that it would introduce, there's pretty much no way that it's ever going to be
> added.

Just the same can be said about bounds checking. And those came into the language, however.

> Walter has been against it every time that it's come up.

Yes, even in the -debug mode. What I fail to see is why. The overhead will be there only if asked for, only in debug mode.

> given the overhead that it would introduce
Do you mean compiler-implementation overhead or resulting runtime overhead?

If you mean runtime overhead then I disagree, as this would be an opt-in option enabled with, say, a version identifier such as version=check_arithmetic_overflow (same as version=assert + friends); it would not be implied by version=debug, so it wouldn't slow down normal debug builds (as the slow down might be significant), but would save hours of debugging to track down overflow bugs when the user requests it explicitly.

I've described this precisely in my post:
http://forum.dlang.org/thread/kn3f9v$25pd$1@digitalmars.com?page=2#post-mailman.161.1369525278.13711.digitalmars-d:40puremagic.com
but it received no answer.



On Tue, Jun 4, 2013 at 12:19 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Tuesday, June 04, 2013 09:14:28 eles wrote:
> > On Monday, 3 June 2013 at 22:19:23 UTC, Ali Çehreli wrote:
> > > On 06/03/2013 03:11 PM, Timothee Cour wrote:
> > > > Why aren't we using version=noboundscheck (+ friends) instead
> > >
> > > of
> > >
> > > > -noboundscheck?
> >
> > Hijack: what about version(integeroverflow)
>
> Nothing in the language checks for integer overflow, and given the overhead
> that it would introduce, there's pretty much no way that it's ever going
> to be
> added. Walter has been against it every time that it's come up.
>
> - Jonathan M Davis
>

On Tuesday, June 04, 2013 00:38:17 Timothee Cour wrote:
> > given the overhead that it would introduce
> 
> Do you mean compiler-implementation overhead or resulting runtime overhead?

I'm talking about runtime overhead, and Walter is flat-out against it. Anyone who wants it even in just non-release mode has to figure out how to convince him, and no one has been able to do that.

- Jonathan M Davis

On Tuesday, June 04, 2013 09:30:07 eles wrote:
> On Tuesday, 4 June 2013 at 07:19:52 UTC, Jonathan M Davis wrote:
> > Walter has been against it every time that it's come up.
> 
> Yes, even in the -debug mode. What I fail to see is why. The overhead will be there only if asked for, only in debug mode.

This is why I hate the -debug flag. Its name causes too much confusion. _All_
that -debug does or will ever do is enable debug {} blocks. It has _nothing_
to do with release builds vs debug builds other than the fact that odds are
you're going to want to use -debug with debug builds and not release builds.
If integer overflow were enabled for "debug" builds it would be enabled when
-release wasn't use - the same as assertions or when a specific flag was used to
enable it.

- Jonathan m Davis

What are his arguments against an opt-in flag such as version=check_arithmetic_overflow ?

* slowing down code is a very weak argument precisely because this would be an opt-in flag (and wouldn't be implied by version=debug in my proposal).

* reliance on intentional overflow arithmetics could be easily protected with version blocks or similar. This should be the exception, not the norm, and I bet we would start finding existing bugs with such a flag enabled.

* the resulting (relatively small) increased complexity of the compiler
would be dwarfed by the time
savings this would enable for everyone in bug chasing mode




On Tue, Jun 4, 2013 at 12:40 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Tuesday, June 04, 2013 00:38:17 Timothee Cour wrote:
> > > given the overhead that it would introduce
> >
> > Do you mean compiler-implementation overhead or resulting runtime
> overhead?
>
> I'm talking about runtime overhead, and Walter is flat-out against it.
> Anyone
> who wants it even in just non-release mode has to figure out how to
> convince
> him, and no one has been able to do that.
>
> - Jonathan M Davis
>