June 18, 2014 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lionello Lunesu | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lionello Lunesu | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 Re: RFC: Value range propagation for if-else | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | 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 |
Copyright © 1999-2021 by the D Language Foundation