Re: DIP 1006 - Preliminary Review Round 1

2018-06-12 Thread Leandro Lucarella via Digitalmars-d
On Tuesday, 6 March 2018 at 10:17:42 UTC, Walter Bright wrote: On 3/6/2018 1:58 AM, Jonathan M Davis wrote: [...] The entire point of making assert a core language feature was so that the compiler could take advantage of it to generate better code. It's been like that for D since day 1. It

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Wednesday, 7 March 2018 at 16:04:50 UTC, Timon Gehr wrote: On 07.03.2018 16:30, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote: On 07.03.2018 15:08, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote: [...]

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Timon Gehr via Digitalmars-d
On 07.03.2018 16:30, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote: On 07.03.2018 15:08, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote: [...] Jonathan, I understand your point, but still I can't find an

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote: On 07.03.2018 15:08, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote: [...] Jonathan, I understand your point, but still I can't find an answer to clarify my doubts. Are we asking for

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Timon Gehr via Digitalmars-d
On 07.03.2018 15:08, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote: On Wednesday, March 07, 2018 13:24:19 Paolo Invernizzi via Digitalmars-d wrote: [...] That would make assertions a lot worse to use, because then they would be in production code

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread ag0aep6g via Digitalmars-d
On 03/07/2018 03:01 PM, Paolo Invernizzi wrote: Are we asking to statically check things like: Assign Expressions [1] Undefined Behavior:   if the lvalue and rvalue have partially overlapping storage   if the lvalue and rvalue's storage overlaps exactly but the types are different A simple

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread ag0aep6g via Digitalmars-d
On 03/07/2018 03:01 PM, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 13:32:37 UTC, ag0aep6g wrote: [...] I don't think anyone is asking for that. The request is for no UB in @safe code. Are we asking to statically check things like: Assign Expressions [1] Undefined Behavior:   if

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Jonathan M Davis via Digitalmars-d
On Wednesday, March 07, 2018 14:08:35 Paolo Invernizzi via Digitalmars-d wrote: > On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis > > wrote: > > On Wednesday, March 07, 2018 13:24:19 Paolo Invernizzi via > > > > Digitalmars-d wrote: > >> [...] > > > > That would make assertions a lot

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote: On Wednesday, March 07, 2018 13:24:19 Paolo Invernizzi via Digitalmars-d wrote: [...] That would make assertions a lot worse to use, because then they would be in production code slowing it down. Also, as it stands,

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Jonathan M Davis via Digitalmars-d
On Wednesday, March 07, 2018 14:01:31 Paolo Invernizzi via Digitalmars-d wrote: > On Wednesday, 7 March 2018 at 13:32:37 UTC, ag0aep6g wrote: > > On Wednesday, 7 March 2018 at 08:58:50 UTC, Paolo Invernizzi > > > > wrote: > >> Just to understand, otherwise, if the assert is removed and it > >>

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Wednesday, 7 March 2018 at 13:32:37 UTC, ag0aep6g wrote: On Wednesday, 7 March 2018 at 08:58:50 UTC, Paolo Invernizzi wrote: Just to understand, otherwise, if the assert is removed and it does not hold, you are in UB, You're not. Just let the compiler treat the code as if the asserts

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Jonathan M Davis via Digitalmars-d
On Wednesday, March 07, 2018 13:24:19 Paolo Invernizzi via Digitalmars-d wrote: > > Right now, since no optimizations like Walter has been talking > > about are done by the compiler, if you have memory corruption, > > you know that you only have to look at @system and @trusted > > code to find

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread ag0aep6g via Digitalmars-d
On Wednesday, 7 March 2018 at 08:58:50 UTC, Paolo Invernizzi wrote: Just to understand, otherwise, if the assert is removed and it does not hold, you are in UB, You're not. Just let the compiler treat the code as if the asserts weren't there. If the resulting code has UB, it won't compile,

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Wednesday, 7 March 2018 at 11:52:05 UTC, Jonathan M Davis wrote: On Wednesday, March 07, 2018 09:22:40 Paolo Invernizzi via Digitalmars-d wrote: On Wednesday, 7 March 2018 at 09:11:10 UTC, Jonathan M Davis wrote: >> So, the request is to just leave assert active as a default >> in @safe

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Jonathan M Davis via Digitalmars-d
On Wednesday, March 07, 2018 09:22:40 Paolo Invernizzi via Digitalmars-d wrote: > On Wednesday, 7 March 2018 at 09:11:10 UTC, Jonathan M Davis > > wrote: > >> So, the request is to just leave assert active as a default in > >> @safe code, like the bounds checks? > > > > No. I'm saying that no

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Wednesday, 7 March 2018 at 09:11:10 UTC, Jonathan M Davis wrote: So, the request is to just leave assert active as a default in @safe code, like the bounds checks? No. I'm saying that no optimizations should be enabled which introduce potential memory corruption. Assertions should have

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Jonathan M Davis via Digitalmars-d
On Wednesday, March 07, 2018 08:39:30 Paolo Invernizzi via Digitalmars-d wrote: > On Tuesday, 6 March 2018 at 20:03:11 UTC, Jonathan M Davis wrote: > > On Tuesday, March 06, 2018 18:49:42 Paolo Invernizzi via > > > > Digitalmars-d wrote: > >> I simply don't understand why enforce or a custom

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Wednesday, 7 March 2018 at 00:11:33 UTC, Timon Gehr wrote: On 06.03.2018 19:49, Paolo Invernizzi wrote: I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. ... I have explained why. UB is non-modular and you don't (want to)

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Tuesday, 6 March 2018 at 23:50:20 UTC, Timon Gehr wrote: On 06.03.2018 10:02, Walter Bright wrote: On 3/6/2018 12:45 AM, Timon Gehr wrote: Anyway, "do not use assert" is not the solution, as I have explained many times now. My interpretation is you want D assert to behave like C assert.

Re: DIP 1006 - Preliminary Review Round 1

2018-03-07 Thread Paolo Invernizzi via Digitalmars-d
On Tuesday, 6 March 2018 at 20:03:11 UTC, Jonathan M Davis wrote: On Tuesday, March 06, 2018 18:49:42 Paolo Invernizzi via Digitalmars-d wrote: I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. If the program must HALT on this or

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Timon Gehr via Digitalmars-d
On 06.03.2018 19:49, Paolo Invernizzi wrote: I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. ... I have explained why. UB is non-modular and you don't (want to) control all the code that you use. Also, enforce cannot be

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Timon Gehr via Digitalmars-d
On 06.03.2018 11:17, Walter Bright wrote: On 3/6/2018 1:58 AM, Jonathan M Davis wrote: [...] The entire point of making assert a core language feature was so that the compiler could take advantage of it to generate better code. It does not need to be a core language feature for that. It

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Timon Gehr via Digitalmars-d
On 06.03.2018 10:02, Walter Bright wrote: On 3/6/2018 12:45 AM, Timon Gehr wrote: Anyway, "do not use assert" is not the solution, as I have explained many times now. My interpretation is you want D assert to behave like C assert. This interpretation is wrong. I, as well as other people,

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Jonathan M Davis via Digitalmars-d
On Tuesday, March 06, 2018 18:49:42 Paolo Invernizzi via Digitalmars-d wrote: > I simply don't understand why enforce or a custom check can't be > used @safe code, if you want that behaviour. > > If the program must HALT on this or that, well, what is better > than an explicit piece of

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread 12345swordy via Digitalmars-d
On Tuesday, 6 March 2018 at 18:49:42 UTC, Paolo Invernizzi wrote: I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. /Paolo Easy: the custom check itself could be wrong the custom check itself is right, but the implementation is

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Paolo Invernizzi via Digitalmars-d
On Tuesday, 6 March 2018 at 17:34:08 UTC, 12345swordy wrote: On Tuesday, 6 March 2018 at 17:24:35 UTC, Jonathan M Davis wrote: On Tuesday, March 06, 2018 16:30:09 John Colvin via Digitalmars-d wrote: On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: > [...] So, to clarify, adding

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread 12345swordy via Digitalmars-d
On Tuesday, 6 March 2018 at 17:24:35 UTC, Jonathan M Davis wrote: On Tuesday, March 06, 2018 16:30:09 John Colvin via Digitalmars-d wrote: On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: > On 3/5/2018 2:30 PM, John Colvin wrote: >> This just feels bad. Adding extra failsafes for

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Jonathan M Davis via Digitalmars-d
On Tuesday, March 06, 2018 16:30:09 John Colvin via Digitalmars-d wrote: > On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: > > On 3/5/2018 2:30 PM, John Colvin wrote: > >> This just feels bad. Adding extra failsafes for my debug > >> program shouldn't make my release program less

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread ag0aep6g via Digitalmars-d
On 03/06/2018 06:01 PM, Paolo Invernizzi wrote: Only if the assert does not hold, you have _not_ tested it, In other words: only if you have a bug in your code. If @safe is only safe as long you don't have bugs, it's no different from @system. So -release turns @safe code into @system code,

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Jonathan M Davis via Digitalmars-d
On Tuesday, March 06, 2018 17:01:04 Paolo Invernizzi via Digitalmars-d wrote: > On Tuesday, 6 March 2018 at 16:30:09 UTC, John Colvin wrote: > > On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: > >> On 3/5/2018 2:30 PM, John Colvin wrote: > >>> This just feels bad. Adding extra

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Paolo Invernizzi via Digitalmars-d
On Tuesday, 6 March 2018 at 16:30:09 UTC, John Colvin wrote: On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: On 3/5/2018 2:30 PM, John Colvin wrote: This just feels bad. Adding extra failsafes for my debug program shouldn't make my release program less safe. Then use

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread John Colvin via Digitalmars-d
On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: On 3/5/2018 2:30 PM, John Colvin wrote: This just feels bad. Adding extra failsafes for my debug program shouldn't make my release program less safe. Then use `enforce()`. So, to clarify, adding asserts to my code makes my

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Jonathan M Davis via Digitalmars-d
On Tuesday, March 06, 2018 02:17:42 Walter Bright via Digitalmars-d wrote: > On 3/6/2018 1:58 AM, Jonathan M Davis wrote: > > [...] > > The entire point of making assert a core language feature was so that the > compiler could take advantage of it to generate better code. It's been > like that for

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Walter Bright via Digitalmars-d
On 3/6/2018 1:58 AM, Jonathan M Davis wrote: [...] The entire point of making assert a core language feature was so that the compiler could take advantage of it to generate better code. It's been like that for D since day 1. It has always been documented to do that. It has been discussed

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Jonathan M Davis via Digitalmars-d
On Monday, March 05, 2018 02:30:12 Walter Bright via Digitalmars-d wrote: > The idea behind removal of the runtime checks is as a performance > optimization done on a debugged program. It's like turning on or off > array bounds checking. Many leave asserts and array bounds checking on > even in

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Walter Bright via Digitalmars-d
On 3/6/2018 12:45 AM, Timon Gehr wrote: Anyway, "do not use assert" is not the solution, as I have explained many times now. My interpretation is you want D assert to behave like C assert. C assert and enforce are purely creatures of the library, with semantics defined by their library

Re: DIP 1006 - Preliminary Review Round 1

2018-03-06 Thread Timon Gehr via Digitalmars-d
On 06.03.2018 03:05, Walter Bright wrote: On 3/5/2018 2:30 PM, John Colvin wrote: This just feels bad. Adding extra failsafes for my debug program shouldn't make my release program less safe. Then use `enforce()`. That makes no sense at all. Enforce is for conditions that are expected to

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Walter Bright via Digitalmars-d
On 3/5/2018 2:30 PM, John Colvin wrote: This just feels bad. Adding extra failsafes for my debug program shouldn't make my release program less safe. Then use `enforce()`.

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Timon Gehr via Digitalmars-d
On 06.03.2018 00:52, ag0aep6g wrote: On 03/05/2018 11:57 PM, Timon Gehr wrote: On 05.03.2018 22:24, ag0aep6g wrote: On 03/05/2018 10:11 PM, Walter Bright wrote: [...] It is not defined behavior with -boundscheck=off. Dereferencing null is not defined with -boundscheck=off? This was my

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread ag0aep6g via Digitalmars-d
On 03/05/2018 11:57 PM, Timon Gehr wrote: On 05.03.2018 22:24, ag0aep6g wrote: On 03/05/2018 10:11 PM, Walter Bright wrote: [...] It is not defined behavior with -boundscheck=off. Dereferencing null is not defined with -boundscheck=off? This was my bad. It's not dereferencing null. The

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Timon Gehr via Digitalmars-d
On 05.03.2018 22:24, ag0aep6g wrote: On 03/05/2018 10:11 PM, Walter Bright wrote: On 3/5/2018 11:34 AM, Timon Gehr wrote: [...]   int[] x=[];   writeln(x[0]); // range violation even with -release // defined behavior even with -boundscheck=off (!) It is not

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread John Colvin via Digitalmars-d
On Monday, 5 March 2018 at 10:30:12 UTC, Walter Bright wrote: The idea behind removal of the runtime checks is as a performance optimization done on a debugged program. It's like turning on or off array bounds checking. Many leave asserts and array bounds checking on even in released code to

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Timon Gehr via Digitalmars-d
On 05.03.2018 22:11, Walter Bright wrote: On 3/5/2018 11:34 AM, Timon Gehr wrote: On 05.03.2018 11:30, Walter Bright wrote: The hints will usually not make a significant difference in performance anyway. Reasonable people will disagree on what is significant or not. ... My point exactly!

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Timon Gehr via Digitalmars-d
On 05.03.2018 21:55, Walter Bright wrote: On 3/5/2018 7:48 AM, Timon Gehr wrote: Again: assert is @safe. Compiler hints are @system. Why should assert give compiler hints? Asserts give expressions that must be true. "Trust the programmer" does not always scale. Why not take advantage of

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread ag0aep6g via Digitalmars-d
On 03/05/2018 09:55 PM, Walter Bright wrote: On 3/5/2018 7:48 AM, Timon Gehr wrote: Again: assert is @safe. Compiler hints are @system. Why should assert give compiler hints? Asserts give expressions that must be true. Why not take advantage of them? Because it's exactly what @safe is not

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread ag0aep6g via Digitalmars-d
On 03/05/2018 10:11 PM, Walter Bright wrote: On 3/5/2018 11:34 AM, Timon Gehr wrote: [...]   int[] x=[];   writeln(x[0]); // range violation even with -release // defined behavior even with -boundscheck=off (!) It is not defined behavior with -boundscheck=off.

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Walter Bright via Digitalmars-d
On 3/5/2018 11:34 AM, Timon Gehr wrote: On 05.03.2018 11:30, Walter Bright wrote: The hints will usually not make a significant difference in performance anyway. Reasonable people will disagree on what is significant or not. It's like turning on or off array bounds checking. It is not.

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Walter Bright via Digitalmars-d
On 3/5/2018 7:48 AM, Timon Gehr wrote: Again: assert is @safe. Compiler hints are @system. Why should assert give compiler hints? Asserts give expressions that must be true. Why not take advantage of them? See Spec# which based an entire language around that notion:

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Timon Gehr via Digitalmars-d
On 05.03.2018 20:41, Iain Buclaw wrote: On Monday, 5 March 2018 at 15:48:12 UTC, Timon Gehr wrote: - Using existing assertions as compiler hints is not necessary. (Without having checked it, I'm sure that LDC/GDC have a more suitable intrinsic for this already.) As far as I can discern,

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Iain Buclaw via Digitalmars-d
On Monday, 5 March 2018 at 18:44:54 UTC, Joseph Rushton Wakeling wrote: On Saturday, 3 March 2018 at 16:33:00 UTC, Martin Nowak wrote: Doesn't really work that way, we can disable assertions, in contracts, out contracts, and invariants. But not assertions in some contexts while leaving them

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Iain Buclaw via Digitalmars-d
On Monday, 5 March 2018 at 15:48:12 UTC, Timon Gehr wrote: - Using existing assertions as compiler hints is not necessary. (Without having checked it, I'm sure that LDC/GDC have a more suitable intrinsic for this already.) As far as I can discern, forcing disabled asserts to give compiler

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Timon Gehr via Digitalmars-d
On 05.03.2018 11:30, Walter Bright wrote: The idea behind removal of the runtime checks is as a performance optimization done on a debugged program. Optimizing performance is fine, but why pessimize safety? The hints will usually not make a significant difference in performance anyway. I

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Joseph Rushton Wakeling via Digitalmars-d
On Saturday, 3 March 2018 at 16:33:00 UTC, Martin Nowak wrote: Doesn't really work that way, we can disable assertions, in contracts, out contracts, and invariants. But not assertions in some contexts while leaving them enabled in other contexts. At least not without modifying all related

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Timon Gehr via Digitalmars-d
On 05.03.2018 11:25, Walter Bright wrote: On 3/4/2018 3:06 PM, Timon Gehr wrote: On 04.03.2018 22:49, Walter Bright wrote: Not necessarily. If the code contains an explicit assertion that the index is in bounds, then, according to the language specification, the bounds check may be removed

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Walter Bright via Digitalmars-d
The idea behind removal of the runtime checks is as a performance optimization done on a debugged program. It's like turning on or off array bounds checking. Many leave asserts and array bounds checking on even in released code to ensure memory safety. At a minimum, turning it off and on will

Re: DIP 1006 - Preliminary Review Round 1

2018-03-05 Thread Walter Bright via Digitalmars-d
On 3/4/2018 3:06 PM, Timon Gehr wrote: On 04.03.2018 22:49, Walter Bright wrote: Not necessarily. If the code contains an explicit assertion that the index is in bounds, then, according to the language specification, the bounds check may be removed with -release. D, as all languages that I

Re: DIP 1006 - Preliminary Review Round 1

2018-03-04 Thread Kagamin via Digitalmars-d
On Sunday, 4 March 2018 at 12:05:08 UTC, rjframe wrote: E.g., "dmd -check=in a.d" is unnecessary; it's equivalent to "dmd a.d" "dmd -release -check=in a.d" turns off all checks except in contracts. I think, -check should specify hierarchic modes like in the DIP, that would work independently

Re: DIP 1006 - Preliminary Review Round 1

2018-03-04 Thread Timon Gehr via Digitalmars-d
On 04.03.2018 22:49, Walter Bright wrote: On 3/4/2018 1:16 PM, Timon Gehr wrote: On 04.03.2018 21:40, Walter Bright wrote: On 3/4/2018 4:05 AM, rjframe wrote: Would I be correct to interpret this as "turn them all off with -release"? Array bounds checking is left on with -release. Not

Re: DIP 1006 - Preliminary Review Round 1

2018-03-04 Thread Walter Bright via Digitalmars-d
On 3/4/2018 1:16 PM, Timon Gehr wrote: On 04.03.2018 21:40, Walter Bright wrote: On 3/4/2018 4:05 AM, rjframe wrote: Would I be correct to interpret this as "turn them all off with -release"? Array bounds checking is left on with -release. Not necessarily. If the code contains an explicit

Re: DIP 1006 - Preliminary Review Round 1

2018-03-04 Thread Timon Gehr via Digitalmars-d
On 04.03.2018 21:40, Walter Bright wrote: On 3/4/2018 4:05 AM, rjframe wrote: Would I be correct to interpret this as "turn them all off with -release"? Array bounds checking is left on with -release. Not necessarily. If the code contains an explicit assertion that the index is in bounds,

Re: DIP 1006 - Preliminary Review Round 1

2018-03-04 Thread Walter Bright via Digitalmars-d
On 3/4/2018 4:05 AM, rjframe wrote: Would I be correct to interpret this as "turn them all off with -release"? Array bounds checking is left on with -release.

Re: DIP 1006 - Preliminary Review Round 1

2018-03-04 Thread rjframe via Digitalmars-d
On Sat, 03 Mar 2018 20:30:31 -0800, Walter Bright wrote: > The default is that they're all on. So to just have one on, first turn > them all off then turn on the desired ones. Would I be correct to interpret this as "turn them all off with -release"? E.g., "dmd -check=in a.d" is unnecessary;

Re: DIP 1006 - Preliminary Review Round 1

2018-03-03 Thread Nicholas Wilson via Digitalmars-d
On Sunday, 4 March 2018 at 04:30:31 UTC, Walter Bright wrote: It's not trivial. First, it's 100 lines of code (with no comments) just for that, and there are templates and behaviors with memory allocation. Moving along that path, we're gradually reinventing std.getopt which is 1814 lines (with

Re: DIP 1006 - Preliminary Review Round 1

2018-03-03 Thread Walter Bright via Digitalmars-d
On 3/3/2018 5:29 PM, Nicholas Wilson wrote: The use of comma-separated arguments is something I've argued against for other switches. The use of `-release=in -release=out` should be fine and is less confusing/buggy to implement. Why?  Implementation is trivial (unit testable no less!) , see

Re: DIP 1006 - Preliminary Review Round 1

2018-03-03 Thread Nicholas Wilson via Digitalmars-d
On Sunday, 4 March 2018 at 00:32:20 UTC, Walter Bright wrote: On 4/12/2017 4:25 AM, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md Currently, we have 3 switches that affect the asserts:

Re: DIP 1006 - Preliminary Review Round 1

2018-03-03 Thread Walter Bright via Digitalmars-d
On 4/12/2017 4:25 AM, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md Currently, we have 3 switches that affect the asserts: `release`, `boundscheck`, and `unittest`. The documentation for

Re: DIP 1006 - Preliminary Review Round 1

2018-03-03 Thread Martin Nowak via Digitalmars-d
On Sunday, 26 November 2017 at 11:59:28 UTC, Joseph Rushton Wakeling wrote: One suggestion: replace -release=assert with -release=body, so in the above, you would have: -release=body,in,out,invariant Doesn't really work that way, we can disable assertions, in contracts, out contracts,

Re: DIP 1006 - Preliminary Review Round 1

2018-03-03 Thread Martin Nowak via Digitalmars-d
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". Possible implementation https://github.com/dlang/dmd/pull/7980 FYI

Re: DIP 1006 - Preliminary Review Round 1

2017-11-27 Thread Mike Parker via Digitalmars-d
On Monday, 27 November 2017 at 19:20:53 UTC, Joseph Rushton Wakeling wrote: What would be the appropriate way to follow up on that idea? The last I saw DIP 1006 was undergoing formal review, but the end of that period seems to have passed with no further follow-up. Formal reviews have

Re: DIP 1006 - Preliminary Review Round 1

2017-11-27 Thread rikki cattermole via Digitalmars-d
On 27/11/2017 7:20 PM, Joseph Rushton Wakeling wrote: On Sunday, 26 November 2017 at 12:09:37 UTC, rikki cattermole wrote: On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote: One suggestion: replace -release=assert with -release=body, so in the above, you would have:

Re: DIP 1006 - Preliminary Review Round 1

2017-11-27 Thread Joseph Rushton Wakeling via Digitalmars-d
On Sunday, 26 November 2017 at 12:09:37 UTC, rikki cattermole wrote: On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote: One suggestion: replace -release=assert with -release=body, so in the above, you would have:     -release=body,in,out,invariant ... which has the nice intuitive

Re: DIP 1006 - Preliminary Review Round 1

2017-11-26 Thread rikki cattermole via Digitalmars-d
On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote: On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md Has come up a couple of times and it's a good idea to allow more control over which checks are enabled. I find

Re: DIP 1006 - Preliminary Review Round 1

2017-11-26 Thread Joseph Rushton Wakeling via Digitalmars-d
On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md Has come up a couple of times and it's a good idea to allow more control over which checks are enabled. I find the suggested switch levels a bit counter-intuitive and

Re: DIP 1006 - Preliminary Review Round 1

2017-11-21 Thread Martin Nowak via Digitalmars-d
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md Has come up a couple of times and it's a good idea to allow more control over which checks are

Re: DIP 1006 - Preliminary Review Round 1

2017-11-21 Thread Martin Nowak via Digitalmars-d
On Wednesday, 12 April 2017 at 15:02:49 UTC, Mathias Lang wrote: I would say that `-contracts=none` and `-unittest` should behave the same as `-release` and `-unittest`, and currently it only turns asserts on (

Re: DIP 1006 - Preliminary Review Round 1

2017-04-27 Thread Steven Schveighoffer via Digitalmars-d
On 4/12/17 12:34 PM, Mathias Lang wrote: On Wednesday, 12 April 2017 at 16:22:00 UTC, Lewis wrote: I have to ask the newbie question, just to make sure we're not missing anything obvious. Why can't we fix invariants so that they're pay-for-what-you-use? In other words, is there a way we can

Re: DIP 1006 - Preliminary Review Round 1

2017-04-27 Thread Mike Parker via Digitalmars-d
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on April 26 (3:59 AM GMT), or when I make a post declaring it complete. The review period has

Re: DIP 1006 - Preliminary Review Round 1

2017-04-26 Thread Olivier FAURE via Digitalmars-d
On Wednesday, 12 April 2017 at 17:16:33 UTC, H. S. Teoh wrote: Overall, I support the idea of this DIP. However, as others have mentioned, it needs to make it clear whether/how `-contracts=assert` here interacts with unittests. According to the discussion, apparently a different druntime

Re: DIP 1006 - Preliminary Review Round 1

2017-04-25 Thread Mike Parker via Digitalmars-d
On Wednesday, 19 April 2017 at 13:28:03 UTC, Mike Parker wrote: On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on April 26 (3:59 AM GMT), or when

Re: DIP 1006 - Preliminary Review Round 1

2017-04-19 Thread Mike Parker via Digitalmars-d
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on April 26 (3:59 AM GMT), or when I make a post declaring it complete. Reminder: There's one

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Timon Gehr via Digitalmars-d
On 12.04.2017 17:16, Mathias Lang wrote: Addressing Daniel Kozak's question as well here: Providing `-release` on the command line has the following effect: - Disable invariants, - Disable in and out, - Disable assert, Actually, (at least) asserts are turned into compiler hints (i.e.

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread H. S. Teoh via Digitalmars-d
On Wed, Apr 12, 2017 at 11:25:09AM +, Mike Parker via Digitalmars-d wrote: > DIP 1006 is titled "Providing more selective control over contracts". > > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md > > All review-related feedback on and discussion of the DIP should occur > in this

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Mathias Lang via Digitalmars-d
On Wednesday, 12 April 2017 at 16:22:00 UTC, Lewis wrote: I have to ask the newbie question, just to make sure we're not missing anything obvious. Why can't we fix invariants so that they're pay-for-what-you-use? In other words, is there a way we can make sure _d_invariant is never called

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Lewis via Digitalmars-d
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on and discussion of the DIP should occur in this thread. The review

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Joseph Rushton Wakeling via Digitalmars-d
On Wednesday, 12 April 2017 at 15:37:14 UTC, Mathias Lang wrote: It was a conscious decision to provide something simple to use, over something which allowed more control (good old KISS). If a use case for it develop in the future, the addition will be trivial. Well, it's not simple to use

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Mathias Lang via Digitalmars-d
On Wednesday, 12 April 2017 at 13:45:08 UTC, Andrea Fontana wrote: On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Mathias Lang via Digitalmars-d
On Wednesday, 12 April 2017 at 12:52:42 UTC, Timon Gehr wrote: On 12.04.2017 13:25, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on and discussion of the DIP

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Mathias Lang via Digitalmars-d
On Wednesday, 12 April 2017 at 11:32:37 UTC, rikki cattermole wrote: On 12/04/2017 12:25 PM, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on and discussion of the

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Andrea Fontana via Digitalmars-d
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on and discussion of the DIP should occur in this thread. The review

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Timon Gehr via Digitalmars-d
On 12.04.2017 13:25, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Daniel Kozak via Digitalmars-d
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on and discussion of the DIP should occur in this thread. The review

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread rikki cattermole via Digitalmars-d
On 12/04/2017 12:48 PM, Nicholas Wilson wrote: On Wednesday, 12 April 2017 at 11:32:37 UTC, rikki cattermole wrote: On 12/04/2017 12:25 PM, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread Nicholas Wilson via Digitalmars-d
On Wednesday, 12 April 2017 at 11:32:37 UTC, rikki cattermole wrote: On 12/04/2017 12:25 PM, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on and discussion of the

Re: DIP 1006 - Preliminary Review Round 1

2017-04-12 Thread rikki cattermole via Digitalmars-d
On 12/04/2017 12:25 PM, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59