June 18, 2014
On Wednesday, 18 June 2014 at 13:00:51 UTC, bearophile wrote:

> I'd like to see and discuss how this could happen.

Note that my discussion so far is about inhibiting run-time checknig of the value range of

struct Bound(T,
             B = T, // bounds type
             B lower = B.min,
             B upper = B.max,
             bool optional = false,
             bool exceptional = true)

defined at

https://github.com/nordlow/justd/blob/master/bound.d

where T is an integer type, that is an Ada-style integer range type.

It would of course be cool if DMD could support this for floating points aswell.

D range indexing/slicing should probably be builtin to the compiler.
June 18, 2014
On Wednesday, 18 June 2014 at 13:12:19 UTC, Nordlöw wrote:

> D range indexing/slicing should probably be builtin to the compiler.

Correction: I mean *inhibiting range checking for array slices* should be built into the compiler.
June 18, 2014
Nordlöw:

> Note that my discussion so far is about inhibiting run-time checknig of the value range of
>
> struct Bound(T,
>              B = T, // bounds type
>              B lower = B.min,
>              B upper = B.max,
>              bool optional = false,
>              bool exceptional = true)

OK. But how?

Bye,
bearophile
June 18, 2014
On Wednesday, 18 June 2014 at 06:40:21 UTC, Lionello Lunesu wrote:
> I got this thing working and I think it's about time I get some comments on it.

This is really cool. Good job!

One thing we need to be careful with is how this is specified.
Because of all the compile time introspection (e.g. __traits
compiles and now __traits intrange), this VRP needs to be
precisely specified otherwise you end up with incompatible
differences between different compiler front ends. I don't want
to see code compiling in one compiler, but not another like we do
in C++ (and if we do, I'd like it to be minimized).

If this goes in, the mechanisms by which is works need to be
added to the spec.
June 18, 2014
On 18/06/14 20:46, "Nordlöw" wrote:
>> Very cool. With your new trait I can simplify and, in turn, reduce
>> compilation time for usages of
>
> Actually, if I'm not mistaken, with this trait, we can inhibit range
> value range checking in run-time when and get all the benefits Ada range
> types currently delivers.
>
> Yet another sales point for D!

I submitted a pull request with the trait, without the if-else stuff! This should be faster to make it in.

https://github.com/D-Programming-Language/dmd/pull/3679

L.
June 18, 2014
On 18/06/14 16:28, bearophile wrote:
> Lionello Lunesu:
>
>>> ubyte foo(immutable int x)
>>> in {
>>>     assert(x >= 0 && x <= ubyte.max);
>>> } body {
>>>     return x;
>>> }
>>
>> Yeah, I wanted to support "assert" as well, but it doesn't create a
>> scope so it'll be a bit trickier to implement.
>
> If you have an assert in a pre-condition and the argument is const, then
> the body{} is the scope you look for.
>
> Bye,
> bearophile

That's a good point! I checked the DMD code and it seems doable. I can reuse the "ConditionVisitor" that I wrote for if-else.

Will play with it.
June 18, 2014
On 18/06/14 16:42, Sönke Ludwig wrote:
> Or even better, "valueRange", to be consistent with the general naming
> convention.

That's what I ended up calling it.
June 18, 2014
Lionello Lunesu:

> Will play with it.

And later you look at other things, like post-conditions:


int foo()
out(result) {
    assert(result >= 0 && result <= ubyte.max);
} body {
    return 10;
}
void main() {
    ubyte x = foo();
}


And slowly D Contract Programming starts to become a grown-up language feature.

Bye,
bearophile
June 18, 2014
On Wednesday, 18 June 2014 at 17:00:36 UTC, bearophile wrote:
> Lionello Lunesu:
>
>> Will play with it.
>
> And later you look at other things, like post-conditions:
>
>
> int foo()
> out(result) {
>     assert(result >= 0 && result <= ubyte.max);
> } body {
>     return 10;
> }
> void main() {
>     ubyte x = foo();
> }
>
>
> And slowly D Contract Programming starts to become a grown-up language feature.
>
> Bye,
> bearophile

This could be a bad thing. It makes it pretty enticing to use contracts as input verification instead of logic verification.
June 18, 2014
On Wed, Jun 18, 2014 at 07:54:02PM +0000, Meta via Digitalmars-d wrote:
> On Wednesday, 18 June 2014 at 17:00:36 UTC, bearophile wrote:
> >Lionello Lunesu:
> >
> >>Will play with it.
> >
> >And later you look at other things, like post-conditions:
> >
> >
> >int foo()
> >out(result) {
> >    assert(result >= 0 && result <= ubyte.max);
> >} body {
> >    return 10;
> >}
> >void main() {
> >    ubyte x = foo();
> >}
> >
> >
> >And slowly D Contract Programming starts to become a grown-up language feature.
> >
> >Bye,
> >bearophile
> 
> This could be a bad thing. It makes it pretty enticing to use contracts as input verification instead of logic verification.

Until you compile with -release, and then suddenly invalid input crashes your program. :-P (Then you'll go and fire the guy who wrote it.)


T

-- 
"The whole problem with the world is that fools and fanatics are always
so certain of themselves, but wiser people so full of doubts." --
Bertrand Russell.
"How come he didn't put 'I think' at the end of it?" -- Anonymous