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
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:
[...]
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
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
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
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
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
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
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,
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
> >>
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
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
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,
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
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
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
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
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)
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.
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
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
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
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,
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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()`.
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
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
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
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
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!
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
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
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.
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.
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:
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,
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
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
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
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
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
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
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
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
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
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
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,
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.
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;
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
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
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:
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
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,
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
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
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:
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
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
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
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
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 (
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
DIP 1006 is titled "Providing more selective control over
contracts". This announcement kicks off the first round of
preliminary reviews. The review thread can be found in the
General forum at:
http://forum.dlang.org/post/rsafosvkhxddkxpta...@forum.dlang.org
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 ET
on April 26 (3:59 AM GMT), or when I
96 matches
Mail list logo
