std.experimental.safeint.d

[Dmitry Olshansky via Digitalmars-d]

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