On 13 April 2013 00:04, Jesse Phillips <Jessekphillips+d@gmail.com> wrote:

> On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:
>
>> 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...
>>
>
> I think this needs to happen prior to the formal review/voting. I would say it should be a precursor to starting the official review, however this would raise the bar too high for things like Jacob's Serialization library; he has a working library, but it isn't ready for Phobos and it would be silly to require the translation prior to approving it for Phobos.
>
> How we choose to add to the exp module would need some consideration.
>

I would say, everything, bar nothing.

The serialisation library is a good example. It's a complicated system, and
it has some history already, offering some confidence from the start.
Experience might suggest that it's more-or-less acceptable into phobos.
It's obviously seen a few projects, but once something is accepted into
phobos, I think it's fair to anticipate its usage to increase
significantly, and in many different kinds of projects.
As an independent library, it might be evaluated by a potential user, and
found not to satisfy the requirements for some reason... they move on and
continue looking at alternatives, nobody's the wiser. Once it's in phobos,
there's a temptation, even an encouragement to use it because it's
'standard'. At this point, it may be found that the project it wasn't
suitable for could be worked with some relatively minor changes, which
should be made, and the library becomes more useful and robust... phobos
doesn't support this pattern at the moment.

I maintain the position that it needs at least a year in the real world before you can truly be confident in it. New things shouldn't be barred from post-release tuning on account of "omg it's a breaking change!".

On Friday, 12 April 2013 at 14:27:25 UTC, Manu wrote:
> On 13 April 2013 00:04, Jesse Phillips <Jessekphillips+d@gmail.com> wrote:
>
>> On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:
>>
>>> 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...
>>>
>>
>> I think this needs to happen prior to the formal review/voting. I would
>> say it should be a precursor to starting the official review, however this
>> would raise the bar too high for things like Jacob's Serialization library;
>> he has a working library, but it isn't ready for Phobos and it would be
>> silly to require the translation prior to approving it for Phobos.
>>
>> How we choose to add to the exp module would need some consideration.
>>
>
> I would say, everything, bar nothing.
>
> The serialisation library is a good example. It's a complicated system, and
> it has some history already, offering some confidence from the start.
> Experience might suggest that it's more-or-less acceptable into phobos.
> It's obviously seen a few projects, but once something is accepted into
> phobos, I think it's fair to anticipate its usage to increase
> significantly, and in many different kinds of projects.
> As an independent library, it might be evaluated by a potential user, and
> found not to satisfy the requirements for some reason... they move on and
> continue looking at alternatives, nobody's the wiser. Once it's in phobos,
> there's a temptation, even an encouragement to use it because it's
> 'standard'. At this point, it may be found that the project it wasn't
> suitable for could be worked with some relatively minor changes, which
> should be made, and the library becomes more useful and robust... phobos
> doesn't support this pattern at the moment.
>
> I maintain the position that it needs at least a year in the real world
> before you can truly be confident in it. New things shouldn't be barred
> from post-release tuning on account of "omg it's a breaking change!".

I strongly agree with this.

There needs to be a middle step between the wild-west of independent libraries and the strictly controlled world of standard library.

http://forum.dlang.org/thread/jcksnp$ah8$1@digitalmars.com

My idea was to ship exp branch with phobos so all users could look into new code. Not all users follow github/newsgroups/etc.

On 13 April 2013 00:41, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:

> http://forum.dlang.org/thread/**jcksnp$ah8$1@digitalmars.com<http://forum.dlang.org/thread/jcksnp$ah8$1@digitalmars.com>
>
> My idea was to ship exp branch with phobos so all users could look into new code. Not all users follow github/newsgroups/etc.
>

Why a branch though? That implies that people are git-savvy (not as common
as you think), and that they even have git installed at all...
It should be an exp directory next to std, so anyone can use it.

On Friday, 12 April 2013 at 15:05:52 UTC, Manu wrote:
> On 13 April 2013 00:41, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:
>
>> http://forum.dlang.org/thread/**jcksnp$ah8$1@digitalmars.com<http://forum.dlang.org/thread/jcksnp$ah8$1@digitalmars.com>
>>
>> My idea was to ship exp branch with phobos so all users could look into
>> new code. Not all users follow github/newsgroups/etc.
>>
>
> Why a branch though? That implies that people are git-savvy (not as common
> as you think), and that they even have git installed at all...
> It should be an exp directory next to std, so anyone can use it.

Agreed. Git should not be required to *use* phobos, only to *contribute* to it.

W dniu 12.04.2013 17:05, Manu pisze:
> On 13 April 2013 00:41, Piotr Szturmaj <bncrbme@jadamspam.pl
> <mailto:bncrbme@jadamspam.pl>> wrote:
>
>     http://forum.dlang.org/thread/__jcksnp$ah8$1@digitalmars.com
>     <http://forum.dlang.org/thread/jcksnp$ah8$1@digitalmars.com>
>
>     My idea was to ship exp branch with phobos so all users could look
>     into new code. Not all users follow github/newsgroups/etc.
>
>
> Why a branch though? That implies that people are git-savvy (not as
> common as you think), and that they even have git installed at all...
> It should be an exp directory next to std, so anyone can use it.

I'm sorry, I really meant exp directory, as another "branch" of phobos - not related to git (or any VCS) in any way.

On 13 April 2013 01:27, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:

> W dniu 12.04.2013 17:05, Manu pisze:
>
>> On 13 April 2013 00:41, Piotr Szturmaj <bncrbme@jadamspam.pl <mailto:bncrbme@jadamspam.pl>> wrote:
>>
>>     http://forum.dlang.org/thread/**__jcksnp$ah8$1@digitalmars.com<http://forum.dlang.org/thread/__jcksnp$ah8$1@digitalmars.com>
>>
>>     <http://forum.dlang.org/**thread/jcksnp$ah8$1@**digitalmars.com<http://forum.dlang.org/thread/jcksnp$ah8$1@digitalmars.com>
>> >
>>
>>     My idea was to ship exp branch with phobos so all users could look
>>     into new code. Not all users follow github/newsgroups/etc.
>>
>>
>> Why a branch though? That implies that people are git-savvy (not as common as you think), and that they even have git installed at all... It should be an exp directory next to std, so anyone can use it.
>>
>
> I'm sorry, I really meant exp directory, as another "branch" of phobos - not related to git (or any VCS) in any way.
>

Fair enough, that thread above went off on a tangent saying they should use branches, so I thought that was the idea.

On Fri, 12 Apr 2013 10:27:11 -0400, Manu <turkeyman@gmail.com> wrote:

> I maintain the position that it needs at least a year in the real world
> before you can truly be confident in it. New things shouldn't be barred
> from post-release tuning on account of "omg it's a breaking change!".

I hate the 'omg it's a breaking change!' mentality as well.  This is an UNRELEASED product.

I also hate the idea of creating another javax.

Here is what I would suggest for new modules (std.log, std.serialization, etc.):

pragma(msg, module.stringof ~ " is experimental, subject to API changes");

After 1 year, remove the pragma, and freeze the API.

Now, if there were only some way to make pragma(msg...) only print out when imported from non-library code...

-Steve

On 13 April 2013 02:07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Fri, 12 Apr 2013 10:27:11 -0400, Manu <turkeyman@gmail.com> wrote:
>
>  I maintain the position that it needs at least a year in the real world
>> before you can truly be confident in it. New things shouldn't be barred from post-release tuning on account of "omg it's a breaking change!".
>>
>
> I hate the 'omg it's a breaking change!' mentality as well.  This is an UNRELEASED product.
>
> I also hate the idea of creating another javax.
>

I don't understand this problem? Why is there a problem moving it when it's
ready?
It's already understood to be experimental, and the user has already
accepted the contract that changes can be made (including moving it to std).

On Sat, 13 Apr 2013 00:27:11 +1000
Manu <turkeyman@gmail.com> wrote:

> On 13 April 2013 00:04, Jesse Phillips <Jessekphillips+d@gmail.com> wrote:
> 
> > On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:
> >
> >> 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...
> >>

While I think you raise a very good point, I agree with the
possible solutions Vladimir suggested in the original thread: Either
add them straight to 'std' from the start and just mark it with a big
red "EXPERIMENTAL" or perhaps more accurately "NEW MODULE -
STILL SUBJECT TO CHANGE!", or make it super-easy to test such modules
when they're in the review queue (perhaps via DUB?). Actually, I'd like
to see *both*.

The "exp vs std" suggestion *could* work, but I think it his a somewhat higher potential for unintended problems down the road.