www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.experimental.safeint.d

reply "Robert burner Schadek" <rburners gmail.com> writes:
SafeInt!T is an integer wrapper struct with an explicit NaN value 
build on top of core.checkedint.

Features:

* checks if assigned values can be actually stored
* for SafeInt!u(T) NaN is T.max
* for SafeInt!T NaN is T.min
* SafeInt!T.opBinary("+","-","%","*","/") return SafeInt!T
   if value can not be store by SafeInt!T returned value is 
SafeInt!T.nan
* should be pretty much a act as any (u)integer type

Additionally, the module contains safe ==,!=,<,<=,>,>= 
comparisons functions

assert(-1 == uint.max); // this is wrongfully true
assert(notEqual(-1, uint.max)); // this asserts correctly true
Jun 07 2015
next sibling parent "Robert burner Schadek" <rburners gmail.com> writes:
PR: https://github.com/D-Programming-Language/phobos/pull/3389
Jun 07 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-07 22:27, Robert burner Schadek wrote:

 SafeInt!T is an integer wrapper struct with an explicit NaN value build
 on top of core.checkedint.


A completely new module should go through the review queue [1] and no 
pull request should be created until it's passed the review.

[1] http://wiki.dlang.org/Review_Queue

-- 
/Jacob Carlborg
Jun 07 2015
next sibling parent "Robert burner Schadek" <rburners gmail.com> writes:
On Monday, 8 June 2015 at 06:43:59 UTC, Jacob Carlborg wrote:

 A completely new module should go through the review queue [1] 
 and no pull request should be created until it's passed the 
 review.


The part about the PR would be a first and quiet useless.
Jun 08 2015
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 08-Jun-2015 09:44, Jacob Carlborg wrote:

 On 2015-06-07 22:27, Robert burner Schadek wrote:

 SafeInt!T is an integer wrapper struct with an explicit NaN value build
 on top of core.checkedint.


 A completely new module should go through the review queue [1] and no
 pull request should be created until it's passed the review.

 [1] http://wiki.dlang.org/Review_Queue


Actually it became quite common to present it as a pull request along 
with documentation (where's DDoc, Robert?). It makes commenting on code 
a breeze. Plus re-use of auto-tester - author has more time to fix his 
stuff should something not work on some platform.

OT: I'm not quite sold on std.experimental as it 100% certain to be a 
breaking change once a module is promoted to std proper or phased out 
for that matter. And, of course, updating anything in std.experimental 
module is going to be a long tedious string of pull requests.

-- 
Dmitry Olshansky
Jun 08 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-06-08 12:33, Dmitry Olshansky wrote:


 Actually it became quite common to present it as a pull request along
 with documentation (where's DDoc, Robert?).


Yeah, I've noticed.


 It makes commenting on code
 a breeze. Plus re-use of auto-tester - author has more time to fix his
 stuff should something not work on some platform.


It's possible to comment on any commit on GitHub. You don't need a pull 
request for that.

-- 
/Jacob Carlborg
Jun 08 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/8/15 6:33 AM, Dmitry Olshansky wrote:


 OT: I'm not quite sold on std.experimental as it 100% certain to be a
 breaking change once a module is promoted to std proper or phased out
 for that matter.


That's the point of it. "If you use this, your code may break."


 And, of course, updating anything in std.experimental
 module is going to be a long tedious string of pull requests.


How so?

-Steve
Jun 08 2015
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 08-Jun-2015 16:36, Steven Schveighoffer wrote:

 On 6/8/15 6:33 AM, Dmitry Olshansky wrote:


 OT: I'm not quite sold on std.experimental as it 100% certain to be a
 breaking change once a module is promoted to std proper or phased out
 for that matter.


 That's the point of it. "If you use this, your code may break."


Okay.


 And, of course, updating anything in std.experimental
 module is going to be a long tedious string of pull requests.


 How so?


Compared to just featuring the code on dub repository:
a) Release cycle tied to dmd
b) All changes must be reviewed
c) Changes got to be small enough to not require long review

Thus overhauls of internals are not going to be easily deliverable,
nor bug-fixes can be got out of band with D distribution.

If anything I'd love to see more 3-rd party stuff that is easily 
installable.

-- 
Dmitry Olshansky
Jun 08 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/8/15 10:03 AM, Dmitry Olshansky wrote:

 On 08-Jun-2015 16:36, Steven Schveighoffer wrote:

 On 6/8/15 6:33 AM, Dmitry Olshansky wrote:

 And, of course, updating anything in std.experimental
 module is going to be a long tedious string of pull requests.


 How so?


 Compared to just featuring the code on dub repository:
 a) Release cycle tied to dmd
 b) All changes must be reviewed
 c) Changes got to be small enough to not require long review

 Thus overhauls of internals are not going to be easily deliverable,
 nor bug-fixes can be got out of band with D distribution.


Yes, that's true. But we are supposed to be having monthly releases of 
DMD with bug fixes at least.

std.experimental is supposed to be relatively stable as compared to an 
outside project. It is going to be tested with auto tester, and ensured 
to work on every PR. I think this is a good thing.

What we CAN do is redesign the API if we don't like it.

I look at std.experimental as "This should have gone into Phobos, but 
we're unsure of whether this API design is the right thing". Currently, 
changing API in phobos is near sacrilege.

Essentially, std.experimental was born out of the realization that 
std.xml API is bad, but we need to keep that API and introduce std.xml2.

Also, using a 3rd party repository does not reach the full audience.


 If anything I'd love to see more 3-rd party stuff that is easily
 installable.


I think code.dlang.org covers that, no?

-Steve
Jun 08 2015
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 08-Jun-2015 17:18, Steven Schveighoffer wrote:

 On 6/8/15 10:03 AM, Dmitry Olshansky wrote:

 On 08-Jun-2015 16:36, Steven Schveighoffer wrote:

 On 6/8/15 6:33 AM, Dmitry Olshansky wrote:

 And, of course, updating anything in std.experimental
 module is going to be a long tedious string of pull requests.


 How so?


 Compared to just featuring the code on dub repository:
 a) Release cycle tied to dmd
 b) All changes must be reviewed
 c) Changes got to be small enough to not require long review

 Thus overhauls of internals are not going to be easily deliverable,
 nor bug-fixes can be got out of band with D distribution.


 Yes, that's true. But we are supposed to be having monthly releases of
 DMD with bug fixes at least.

 std.experimental is supposed to be relatively stable as compared to an
 outside project. It is going to be tested with auto tester, and ensured
 to work on every PR. I think this is a good thing.

 What we CAN do is redesign the API if we don't like it.
 I look at std.experimental as "This should have gone into Phobos, but
 we're unsure of whether this API design is the right thing". Currently,
 changing API in phobos is near sacrilege.

 Essentially, std.experimental was born out of the realization that
 std.xml API is bad, but we need to keep that API and introduce std.xml2.

 Also, using a 3rd party repository does not reach the full audience.



 If anything I'd love to see more 3-rd party stuff that is easily
 installable.


 I think code.dlang.org covers that, no?


That much is true, I'm just hoping we move on to boost 3rd party 
projects instead of dumping modules in std.exp adding more strain on the 
relatively scarce forces of the core team.

I have no specific plan though, but surely it needs a bit of help. Maybe 
adding some flags so that "good" projects that pass builds/tests with 
recent DMD or LDC/GDC are highlighted.

-- 
Dmitry Olshansky
Jun 08 2015
prev sibling parent "Robert burner Schadek" <rburners gmail.com> writes:
On Monday, 8 June 2015 at 10:33:12 UTC, Dmitry Olshansky wrote:

 along with documentation (where's DDoc, Robert?).


http://burner.github.io/phobos/phobos-prerelease/std_experimental_safeint.html
Jun 08 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/7/2015 1:27 PM, Robert burner Schadek wrote:

 SafeInt!T is an integer wrapper struct with an explicit NaN value build on top
 of core.checkedint.


Bearophile ought to like this!
Jun 08 2015