It is that time, If you would like to see the proposed std.process include into Phobos please vote yes. If one condition must be met specify under what condition, otherwise vote no.

std.process by Lars Kyllingstad and Steven Schveighoffer is a suggested improvement to the existing std.process and is a major change to the API. The original API remains but these will be going through deprecation.

In summary of the discussion there was concern of the use of Error and Exception. Lars is very interested in getting the standard hierarchy http://wiki.dlang.org/DIP33 thus leaving these at the safest level to allow for change without breaking code.

Please place any further comments in the official review thread leaving only your vote and a short comment (there should be no need to reply to anyone).

Docs: http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process.html

Source: https://github.com/kyllingstad/phobos/blob/std-process2/std/process.d

Friday April 19 PST will be the last day of voting.

On Friday, 12 April 2013 at 04:46:52 UTC, Jesse Phillips wrote:
> It is that time, If you would like to see the proposed std.process include into Phobos please vote yes.

Yes!

On Fri, 12 Apr 2013 06:46:51 +0200
"Jesse Phillips" <Jessekphillips+d@gmail.com> wrote:

> It is that time, If you would like to see the proposed std.process include into Phobos please vote yes. If one condition must be met specify under what condition, otherwise vote no.
> 

Yes

Sorry to derail the topic, but I'd just like to raise a major gripe I've had with introducing anything into phobos recently.

I see this pattern where something is designed, discussed, and then voted
into phobos. At this time the design looks good on paper, but there is very
little practical experience using the library.
The problem then is, once accepted, people start using it, and at some
point some issues are found, or ideas for improvement are made based on
user experience, but the module can no longer be touched due to the general
phobia of making breaking changes...

Can I suggest that ALL new modules should be added to exp. rather than
std.? Here they will stay for at least 1 year, and while they live in exp,
it is understood that they are still in an experimental introductory phase.
Users who choose to use modules in exp are accepting that the API may
receive changes, and consequently, accepting the responsibility to update
their code (and not complain about it breaking their program), should the
library be amended in its introductory phase.
At some time later when the module has been used in a decent amount of
software, and the API has stabilised, it can then be moved to std. This
move is obviously a breaking change its self, but anyone who has agrees to
import exp modules has already accepted the responsibility to update their
code as such.

Thoughts?


On 12 April 2013 16:12, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com
> wrote:

> On Fri, 12 Apr 2013 06:46:51 +0200
> "Jesse Phillips" <Jessekphillips+d@gmail.com> wrote:
>
> > It is that time, If you would like to see the proposed std.process include into Phobos please vote yes. If one condition must be met specify under what condition, otherwise vote no.
> >
>
> Yes
>

Yes.

On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:
> Sorry to derail the topic, but I'd just like to raise a major gripe I've
> had with introducing anything into phobos recently.
>
> I see this pattern where something is designed, discussed, and then voted
> into phobos. At this time the design looks good on paper, but there is very
> little practical experience using the library.
> The problem then is, once accepted, people start using it, and at some
> point some issues are found, or ideas for improvement are made based on
> user experience, but the module can no longer be touched due to the general
> phobia of making breaking changes...
>
> Can I suggest that ALL new modules should be added to exp. rather than
> std.? Here they will stay for at least 1 year, and while they live in exp,
> it is understood that they are still in an experimental introductory phase.
> Users who choose to use modules in exp are accepting that the API may
> receive changes, and consequently, accepting the responsibility to update
> their code (and not complain about it breaking their program), should the
> library be amended in its introductory phase.
> At some time later when the module has been used in a decent amount of
> software, and the API has stabilised, it can then be moved to std. This
> move is obviously a breaking change its self, but anyone who has agrees to
> import exp modules has already accepted the responsibility to update their
> code as such.
>
> Thoughts?
>
>
> On 12 April 2013 16:12, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com
>> wrote:
>
>> On Fri, 12 Apr 2013 06:46:51 +0200
>> "Jesse Phillips" <Jessekphillips+d@gmail.com> wrote:
>>
>> > It is that time, If you would like to see the proposed
>> > std.process include into Phobos please vote yes. If one condition
>> > must be met specify under what condition, otherwise vote no.
>> >
>>
>> Yes


Fully agree

On 2013-04-12 08:24, Manu wrote:

> Thoughts?

I think it's a good idea.

-- 
/Jacob Carlborg

On 4/12/13, Jesse Phillips <Jessekphillips+d@gmail.com> wrote:
> It is that time, If you would like to see the proposed std.process include into Phobos please vote yes. If one condition must be met specify under what condition, otherwise vote no.

Yes.

On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:
> Can I suggest that ALL new modules should be added to exp. rather than
> std.?

Java tried this. As a result, they are now stuck with "javax" because they realized breaking backwards compatibility wasn't worth the benefit of "graduating" packages from "javax" to "java".

If the goal is to include new or newly-overhauled modules in official releases, I think simply putting a big red "EXPERIMENTAL" warning at the top of the documentation would be simpler. Then, the warning can be removed when there is a D release which has no breaking changes in said module since its last released version.

However, another direction would be to make it easier to test such fresh modules. For example, it would be nice to have "nightly" builds of D, both for the "master" version, and a "mob" version, which includes some work-in-progress developments.

> ...
> Thoughts?

Right suggestion.

As it was already discussed once, D community could follow Linux in this regard: each new module enters 'staging' folder. At some point in time it goes into 'mainline'.
This could also streamline the process of deprecating the old library.