https://issues.dlang.org/show_bug.cgi?id=23296
--- Comment #2 from Dlang Bot ---
dlang/dlang.org pull request #3379 "[spec/type] Add Value Range Propagation
section" was merged into master:
- 4fccfa8011c3a4064aa962819e25c969e5cee3d7 by Nick Treleaven:
Fix Issue 23296 - Value Range P
https://issues.dlang.org/show_bug.cgi?id=23296
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=23296
--- Comment #1 from Dlang Bot ---
@ntrel updated dlang/dlang.org pull request #3379 "[spec/type] Add Value Range
Propagation section" fixing this issue:
- Fix Issue 23296 - Value Range Propagation not documented
https://github.com/dlang
https://issues.dlang.org/show_bug.cgi?id=23296
Nick Treleaven changed:
What|Removed |Added
Keywords||pull, spec
--
https://issues.dlang.org/show_bug.cgi?id=23296
Issue ID: 23296
Summary: Value Range Propagation not documented
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority
https://issues.dlang.org/show_bug.cgi?id=3147
Andrei Alexandrescu and...@erdani.com changed:
What|Removed |Added
Version|2.038 |D2
--
range propagation to disable some slice bound tests
https://github.com/D-Programming-Language/dmd/commit/68260d6cbaff13e93257bdba97d9d868a76b0dda
Merge pull request #4293 from 9rnsr/fix13976
--
https://issues.dlang.org/show_bug.cgi?id=13976
--- Comment #4 from Per Nordlöw per.nord...@gmail.com ---
Correction:
x[0 .. $/2, $2..$]
should of course be
x[0 .. $/2, $/2..$]
--
https://issues.dlang.org/show_bug.cgi?id=13976
Per Nordlöw per.nord...@gmail.com changed:
What|Removed |Added
CC||per.nord...@gmail.com
https://issues.dlang.org/show_bug.cgi?id=13777
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=13777
--- Comment #3 from bearophile_h...@eml.cc ---
(In reply to Kenji Hara from comment #2)
With 2.057 to 2.066 and git-head, the code fails to compile because T is
deduced to int and an int function return is not always implicitly
convertible to
https://issues.dlang.org/show_bug.cgi?id=13777
--- Comment #4 from Kenji Hara k.hara...@gmail.com ---
(In reply to bearophile_hugs from comment #3)
(In reply to Kenji Hara from comment #2)
With 2.057 to 2.066 and git-head, the code fails to compile because T is
deduced to int and an int
https://issues.dlang.org/show_bug.cgi?id=13777
--- Comment #2 from Kenji Hara k.hara...@gmail.com ---
(In reply to Denis Shelomovskij from comment #0)
This code used to work:
---
T select(T)(in size_t idx, T[2] values...)
{
return values[idx];
}
void main()
{
ubyte ub =
https://issues.dlang.org/show_bug.cgi?id=13777
Issue ID: 13777
Summary: Value range propagation faild on array function
argument
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
https://issues.dlang.org/show_bug.cgi?id=13777
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment
This is the first part of a function to convert to base 58 (some
letters are missing, like the upper case I) used in the Bitcoin
protocol:
alias Address = ubyte[1 + 4 + RIPEMD160_digest_len];
char[] toBase58(ref Address a) pure nothrow @safe {
static immutable symbols = 123456789 ~
Latest [1] now also supports CTFE:
const i = foo ? -1 : 33;
if (i)
static assert(__traits(intrange, i) == Tuple!(-1, 33));
else
{
static assert(i == 0); // Works now!
static assert(__traits(intrange, i) == Tuple!(0, 0));
}
if (i == 33)
{
On 18 June 2014 16:40, Lionello Lunesu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Hi,
I got this thing working and I think it's about time I get some comments on
it.
I've been wanting to extend Value Rang Propagation (VRE) for some time now.
Mostly because of the fix to the
On Monday, 30 June 2014 at 07:47:22 UTC, Lionello Lunesu wrote:
Latest [1] now also supports CTFE:
const i = foo ? -1 : 33;
if (i)
static assert(__traits(intrange, i) == Tuple!(-1, 33));
else
{
static assert(i == 0); // Works now!
static
https://issues.dlang.org/show_bug.cgi?id=10018
--- Comment #11 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/45a26d5d89c22b74bf4cc9f37eaad8c21c53ea80
Issue 10018 - Add VRP
https://issues.dlang.org/show_bug.cgi?id=10018
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://issues.dlang.org/show_bug.cgi?id=10018
Lionello Lunesu lio+bugzi...@lunesu.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://issues.dlang.org/show_bug.cgi?id=10018
Lionello Lunesu lio+bugzi...@lunesu.com changed:
What|Removed |Added
Keywords||pull
--- Comment
On 23/06/14 04:51, Nordlöw wrote:
That will only work now if you use an else.
So you mean something like
if(xbyte.min || xbyte.max)
throw new InvalidArgumentException(...
else {}
?
That seems like a strange restriction. Why is that?
I meant, else return x;
Because
On 2014-06-23 13:13:37 +, bearophile said:
Daniel Murphy:
What happens when a function is called from different places with
values with different ranges? What about when it's called from another
compilation unit?
One solution is to ignore such cases, so that feature gives useful
Shammah Chancellor:
Wouldn't that cause compiler errors that only happen depending
on what order you compile things?
If you refer to the first solution, then the answer is yes. The
ability to catch bugs at compile-time is not fully deterministic,
it's a help for the programmer, but it's not
On Sunday, 22 June 2014 at 21:10:31 UTC, bearophile wrote:
Nordlöw:
auto pow(T)(T arg, uint n)
{
enum vr = __traits(valueRange, arg);
static if (vr.min == vr.max) // if arg is constant
I think that unfortunately this currently can't work, you can't
tell the range of the input value
I think that unfortunately this currently can't work, you can't
tell the range of the input value like that. I have explained
why in one of my posts in this thread. Please try to explain me
why I'm wrong.
I'm currently merely talking about possibilities in this case, so
I cannot currently
Nordlöw wrote in message news:jctlkqtiztnbnctld...@forum.dlang.org...
I'm currently merely talking about possibilities in this case, so I cannot
currently prove you wronge ;) To me it seem like an unneccessary
limitation that valueRanges aren't propagated to function call arguments
provided
Daniel Murphy:
What happens when a function is called from different places
with values with different ranges? What about when it's called
from another compilation unit?
One solution is to ignore such cases, so that feature gives
useful results only when the source is compiled in the same
On Monday, 23 June 2014 at 12:51:58 UTC, Daniel Murphy wrote:
What happens when a function is called from different places
with values with different ranges? What about when it's called
from another compilation unit? Generally the argument ranges
can only be known when the function is
On Monday, 23 June 2014 at 13:13:38 UTC, bearophile wrote:
One solution is to ignore such cases, so that feature gives
useful results only when the source is compiled in the same
compilation unit.
An alternative solution is to handle the functions that use
those features like templates, and
to create the patch that
implements the value range propagation for if-else. Exposing the
range and implementing value range propagation for if-else are
sufficiently distinct needs.
Bye,
bearophile
That will only work now if you use an else.
So you mean something like
if(xbyte.min || xbyte.max)
throw new InvalidArgumentException(...
else {}
?
That seems like a strange restriction. Why is that?
static if (this.min = r[0]
r[1] = this.max)
BTW: I believe valueRange also enables specialization of constant
arguments inside existing functions without having to move them
to template arguments of specialized functions. Showcase:
auto pow(T)(T arg, uint n)
{
Correction:
It should of course be
auto pow(T)(T arg, uint n)
{
enum vr = __traits(valueRange, n);
}
Nordlöw:
auto pow(T)(T arg, uint n)
{
enum vr = __traits(valueRange, arg);
static if (vr.min == vr.max) // if arg is constant
I think that unfortunately this currently can't work, you can't
tell the range of the input value like that. I have explained why
in one of my posts in this
range propagation in this {min, max}
form, but I think that's an implementation detail. It's well
suited for arithmetic operations, but less suitable for logical
operations. For example, this code can't overflow, but {min, max}
range propagation thinks it can.
ubyte foo ( uint a) {
return
?
The compiler uses value range propagation in this {min, max} form, but I
think that's an implementation detail. It's well suited for arithmetic
operations, but less suitable for logical operations. For example, this
code can't overflow, but {min, max} range propagation thinks it can.
ubyte foo
On 06/18/2014 09:54 PM, Meta wrote:
...
This could be a bad thing. It makes it pretty enticing to use contracts
as input verification instead of logic verification.
The following is doable as well with a standard range analysis:
byte foo(immutable int x){
if(xbyte.min || xbyte.max)
void main() {
import std.bigint;
BigInt[] arr = [10, 20];
import std.numeric;
alias I10 = Bound!(int, 0, 10);
I10[] arr = [8, 6, 20];
}
In the meantime Kenji delivers, those BigInt array literals are
possible with this patch:
H. S. Teoh:
This is a different instance of the same problem as above,
isn't it?
If Bound has access to compiler knowledge about value ranges,
then it
would be able to statically reject out-of-range values.
Yes, with the latest patch by Kenji it's thankfully an instance
of the same problem
On 19/06/14 15:59, Timon Gehr wrote:
On 06/18/2014 09:54 PM, Meta wrote:
...
This could be a bad thing. It makes it pretty enticing to use contracts
as input verification instead of logic verification.
The following is doable as well with a standard range analysis:
byte foo(immutable int
Hi,
I got this thing working and I think it's about time I get some comments
on it.
I've been wanting to extend Value Rang Propagation (VRE) for some time
now. Mostly because of the fix to the troublesome signed-unsigned
comparisons issue. Enabling VRE for if-else and will fix many of
the
I'd like a name like integral_range,
value_range seems better, more general.
Bye,
bearophile
Lionello Lunesu:
I've also added a __traits(intrange, expression) which
returns a tuple with the min and max for the given expression.
I'd like a name like integral_range, and perhaps it's better for
it to return a T[2] (fixed size array) instead of a tuple.
Such __traits(integral_range,
On 18/06/14 15:53, bearophile wrote:
I've also added a __traits(intrange, expression) which returns a
tuple with the min and max for the given expression.
I'd like a name like integral_range, and perhaps it's better for it to
return a T[2] (fixed size array) instead of a tuple.
Most other
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,
There, I've also added a __traits(intrange, expression) which
Very cool. With your new trait I can simplify and, in turn,
reduce compilation time for usages of
https://github.com/nordlow/justd/blob/master/bound.d
I'm looking forward to the merge :)
Am 18.06.2014 09:54, schrieb bearophile:
I'd like a name like integral_range,
value_range seems better, more general.
Bye,
bearophile
Or even better, valueRange, to be consistent with the general naming
convention.
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
Nordlöw:
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.
I'd like to see and discuss how this could happen.
Bye,
bearophile
I'd like to see and discuss how this could happen.
Certainly! I'm available later on this evening at, say, 20.00 CET.
/Per
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.
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,
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.
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
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.
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
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.
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
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();
}
On Wed, Jun 18, 2014 at 07:54:02PM +, 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 =
On Wednesday, 18 June 2014 at 20:00:20 UTC, H. S. Teoh via
Digitalmars-d wrote:
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
My point exactly. If contracts allow things like what Bearophile
Destroy!
Correction:
static if (this.min = r[0]
r[1] = this.max)
On Wednesday, 18 June 2014 at 13:31:01 UTC, bearophile wrote:
OK. But how?
The simplest example is probably the constructor for Bound
defined something like
this(T value)
{
enum r = __traits(valueRange, value);
static if (this.min = r[0]
this.max = r[1])
{
On Wednesday, 18 June 2014 at 17:00:36 UTC, bearophile wrote:
And slowly D Contract Programming starts to become a grown-up
language feature.
Interesting!
Meta:
My point exactly. If contracts allow things like what
Bearophile wants to work, then people might use them to do
input/output validation instead of validating basic
assumptions, like they're supposed to do. Then we have problems
like you described. Maybe it's a good idea to keep
or mitigate this problem is to leave available the source
code of functions with an enum pre-conditions, just like with
templates. Perhaps this is not a big problem because enum
preconditions and constructor value range propagation are meant
to be used mostly in library code, like in Bound integers
On Wed, Jun 18, 2014 at 10:08:06PM +, bearophile via Digitalmars-d wrote:
[...]
D language is designed to allow you to create data structures in
library code able to act a lot like built-in features (so there's a
refined operator overloading, opCall, static opCall, and even more
unusual
On Wednesday, 18 June 2014 at 14:10:11 UTC, Peter Alexander wrote:
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
Hello,
Firstly, I'm not an actual D programmer. I'm doing a college
research about D language.
My point here is that I faced the following situation.
With the code above
void main() {
fun(1f);
fun(1);
fun(1L);
fun!(long)(1L);
}
void fun(T)(T
On 2014-05-22 7:37 PM, Wagner Macedo wrote:
fun(1);
fun(1L);
fun!(long)(1L);
Non-template functions are preferred over template, they have priority
even when it's done with implicit conversion.
This is the case for C++ as well.
Etienne:
Non-template functions are preferred over template, they have
priority even when it's done with implicit conversion.
This is the case for C++ as well.
Perhaps Rust doesn't have function overloading?
Bye,
bearophile
On Friday, 23 May 2014 at 00:04:00 UTC, Etienne wrote:
Non-template functions are preferred over template, they have
priority even when it's done with implicit conversion.
This is the case for C++ as well.
Nordlöw:
I cracked it:
This is important stuff. So if you find that you can't do
something in D, consider asking for it in the main D newsgroup
and in Bugzilla.
Bye,
bearophile
I'm trying to extend my wrapper class Bound to support CTFE Value
Range Propagation in primary in opUnary and opBinary similar to
what Ada's Range Types.
My current try so far for binary arithmetic is
auto opBinary(string op, U,
U lower_rhs = U.min,
U
Ideas anyone?
I cracked it:
auto opBinary(string op, U,
string file = __FILE__,
int line = __LINE__)(U rhs)
{
static if (is(U == Bound))
{
alias C = CommonType!(T, U.type);
Bound!(C,
https://d.puremagic.com/issues/show_bug.cgi?id=10018
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=10018
--- Comment #6 from bearophile_h...@eml.cc 2013-07-20 13:58:03 PDT ---
Se also Issue 10685 , Issue 10615 , Issue 10594
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because:
http://d.puremagic.com/issues/show_bug.cgi?id=10018
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
---
http://d.puremagic.com/issues/show_bug.cgi?id=9097
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
/186acf411866c1950b215f58fd57c08e903f588c
Fix Issue 9097 - Value range propagation to disable some array bound tests
Do not emit bounds check code if the index is statically known to be within
bounds
https://github.com/D-Programming-Language/dmd/commit/fe9bb4aaad8b9aa132bd86d7a1168be12fec5981
Merge pull request #1493 from yebblies
http://d.puremagic.com/issues/show_bug.cgi?id=9097
--- Comment #3 from bearophile_h...@eml.cc 2013-07-09 03:15:11 PDT ---
In past dmd generated this with dmd -O -inline -release -noboundscheck:
__Dmain:
sub ESP, 0330h
mov ECX, 0C8h
push EDI
mov EAX, 0338h[ESP]
add EAX,
http://d.puremagic.com/issues/show_bug.cgi?id=10018
Summary: Value range propagation for immutable variables
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=10018
--- Comment #1 from Lionello Lunesu lio+bugzi...@lunesu.com 2013-05-02
12:32:38 PDT ---
https://github.com/D-Programming-Language/dmd/pull/1955
Not sure how to test this. There's no [portable] way of testing whether a range
is being
http://d.puremagic.com/issues/show_bug.cgi?id=10018
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=10018
--- Comment #3 from Lionello Lunesu lio+bugzi...@lunesu.com 2013-05-02
17:35:02 PDT ---
(In reply to comment #2)
I don't understand the bug, what's the issue here?
Any calculation with 'i' that uses VRP get the full int range, not the
http://d.puremagic.com/issues/show_bug.cgi?id=10018
Lionello Lunesu lio+bugzi...@lunesu.com changed:
What|Removed |Added
Priority|P2 |P4
---
http://d.puremagic.com/issues/show_bug.cgi?id=9097
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Keywords||pull
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=9097
Summary: Value range propagation to disable some array bound
tests
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
http://d.puremagic.com/issues/show_bug.cgi?id=3147
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=3147
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
http://d.puremagic.com/issues/show_bug.cgi?id=3147
--- Comment #11 from bearophile_h...@eml.cc 2011-06-16 05:30:16 PDT ---
This example was in bug 5528:
void main() {
uint i = 10;
ubyte x1 = i % ubyte.max;
ulong l = 10;
uint x2 = l % uint.max;
}
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=3147
kenn...@gmail.com changed:
What|Removed |Added
Keywords||patch
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=6000
kenn...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://d.puremagic.com/issues/show_bug.cgi?id=3147
--- Comment #8 from kenn...@gmail.com 2011-06-12 11:06:25 PDT ---
*** Issue 6000 has been marked as a duplicate of this issue. ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this
http://d.puremagic.com/issues/show_bug.cgi?id=3147
kenn...@gmail.com changed:
What|Removed |Added
CC||dfj1es...@sneakemail.com
---
http://d.puremagic.com/issues/show_bug.cgi?id=6000
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
---
http://d.puremagic.com/issues/show_bug.cgi?id=6000
Summary: Value range propagation does not work with modulus (%)
with a constant
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
1 - 100 of 223 matches
Mail list logo
