On Monday, 26 January 2015 at 21:51:03 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 19:50:39 UTC, H. S. Teoh wrote:
>> If it takes just as much effort to get it into std.experimental as it
>> would take to get into std directly, I don't see the point of the
>> additional hassle introduced by std.experimental.
>>
>>
>> T
>
> I agree - be shameless with what you put in std.experimental. Otherwise it has no purpose. Really, the whole point of such a package is so you can safely *ignore* all the trolls and naysayers on reddit, newsgroups, slashdot, etc... so that you can work on the libraries. There should be no shame whatsoever in breaking code that uses std.experimental, nor any pretense that it's anything but a playground for working out kinks. std.experimental is a warehouse where things are tried and scrapped regularly. The only reason it exists is to say that these particular *kinds* of tasks are "preapproved" for phobos. It says *nothing* about whether the current implementation will be here next month or not. Everything in std.experimental is "still in the shop", subject to complete and instantaneous recall at any time.
>
> Otherwise, ask yourself, what's the point of std.experimental at all? You just like giving people 13 extra characters to type when you make guarantees?

+1, I'd love to see more experimental possibly-later approved modules in std.experimental.

On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek wrote:
> thank you @!"In order of appearance on github"() { Dicebot, JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce, yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky, SerialVelocity, drasha, klickverbot, MartinNowak, jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }
>
> and anyone I forgot
>
> thank you very very much

Well complaining is easy. Doing is harder. Thanks to you.

On Monday, 26 January 2015 at 18:19:18 UTC, H. S. Teoh wrote:
> On Mon, Jan 26, 2015 at 10:09:45AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>> ...is what took to get std.experimental.logger in Phobos.
>> 
>> https://github.com/D-Programming-Language/phobos/pull/1500
>> 
>> A time to celebrate! Many thanks to Robert who carried it through a
>> long gestation, Dicebot for managing the review process, and everybody
>> who provided feedback, especially Martin Nowak for his ideas.
> [...]
>
> Certainly, this deserves celebration!
>
> But OTOH, if *this* is what it takes to contribute a new module to
> Phobos, then it's no wonder we have trouble finding contributors...
> Most would give up before they even try. I think there's an imbalance
> here between the quality of existing Phobos modules vs. the quality
> expected of future Phobos modules.

To be quite frank, the code was initially quite bad. Design decisions aside, there were many errors like not using attributes correctly and having messy algorithms with exponential time complexity. This hasn't been the case with all Phobos proposals.

(Also, valid criticisms were sometimes forgotten for a long time, and there were sometimes several months between patches, but things like these are unavoidable in a volunteer environment.)

> Whatever happened to incremental
> refinement??  Do we really expect flawless perfection before merging to,
> of all places, std.*experimental*?
>
>
> T

The deal to include it into std.experimental was only introduced at the very end of the review process.

"weaselcat"  wrote in message news:ovwpcitsqbmpusckkghl@forum.dlang.org... 

> Following this timeline, we should get std.allocator sometime next year? : )

2019

On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu
wrote:
> On 1/26/15 12:30 PM, Dicebot wrote:
>> We couldn't merge it into std.experimental before because you have
>> stated that even std.experimental modules shouldn't have a breaking
>> changes normally. It was 2 reviews ago.
>>
>> Now you have reconsidered, which is understandable considering how long
>> has it been taking, but pretending that was intended to work that way
>> does not make you look good :(
>>
>> PS I was in favor for very lax initial requirements for experimental
>> packages for this very reason.
>
> Now I remember. I admit I was wrong. -- Andrei

I thought the idea was that there should be no _known_ pending
breaking changes when mergin into std.experimental. Thus
std.experimental would be for fixing problems that are found when
the package is actually used. Breaking changes for fixing those
would be perfectly fine.

1. review => if problems found => fix all known problems and
repeat the review
2. once everyting seems ok in review => merge to std.experimental
3. if a new problem requiring a breaking change is found => fix it
4. once no new problems have been found for a while => seems ok
=> merge to std
5. if a new problem requiring a breaking change is found => can't
fix it, maybe try to cirmumvent it somehow etc. (no breaking
changes unless it's critical)

On Tuesday, 27 January 2015 at 09:07:30 UTC, tn wrote:
> On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu
> wrote:
>> On 1/26/15 12:30 PM, Dicebot wrote:
>>> We couldn't merge it into std.experimental before because you have
>>> stated that even std.experimental modules shouldn't have a breaking
>>> changes normally. It was 2 reviews ago.
>>>
>>> Now you have reconsidered, which is understandable considering how long
>>> has it been taking, but pretending that was intended to work that way
>>> does not make you look good :(
>>>
>>> PS I was in favor for very lax initial requirements for experimental
>>> packages for this very reason.
>>
>> Now I remember. I admit I was wrong. -- Andrei
>
> I thought the idea was that there should be no _known_ pending
> breaking changes when mergin into std.experimental. Thus
> std.experimental would be for fixing problems that are found when
> the package is actually used. Breaking changes for fixing those
> would be perfectly fine.
>
> 1. review => if problems found => fix all known problems and
> repeat the review
> 2. once everyting seems ok in review => merge to std.experimental
> 3. if a new problem requiring a breaking change is found => fix it
> 4. once no new problems have been found for a while => seems ok
> => merge to std
> 5. if a new problem requiring a breaking change is found => can't
> fix it, maybe try to cirmumvent it somehow etc. (no breaking
> changes unless it's critical)

I found out I quite like the Rust's way of doing this because it's changing so much and so fast -- plain and simple, unstable features are put behind "feature gates" and the only way for the end user to use unstable API is to explicitly mark it as allowing the unstable code. This also goes well with RFC review process. Once the feature is stabilized, no changes to user code are required, no imports to be changed etc. This allows them to merge in ridiculous amount of PRs/day and test everything out live without affecting the core stable API.

Congratulations to all involved for the effort to bring this completion. I am very glad that we now have a standard way of logging in Phobos :)



On Monday, 26 January 2015 at 18:09:46 UTC, Andrei Alexandrescu wrote:
> ...is what took to get std.experimental.logger in Phobos.
>
> https://github.com/D-Programming-Language/phobos/pull/1500
>
> A time to celebrate! Many thanks to Robert who carried it through a long gestation, Dicebot for managing the review process, and everybody who provided feedback, especially Martin Nowak for his ideas.
>
>
> Andrei

On Tuesday, 27 January 2015 at 00:05:20 UTC, deadalnix wrote:
> On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek wrote:
>> thank you @!"In order of appearance on github"() { Dicebot, JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce, yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky, SerialVelocity, drasha, klickverbot, MartinNowak, jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }
>>
>> and anyone I forgot
>>
>> thank you very very much
>
> Well complaining is easy. Doing is harder. Thanks to you.

Just an FYI:
I'm sure you meant to sincerely thank Robert, but the above reads like you are blaming him for it being harder to do than to complain. "Thanks to you" is dangerous to put near anything negative as it's just a commonly used sarcastically as it is sincerely. English is weird :)

On Tuesday, 27 January 2015 at 11:43:48 UTC, John Colvin wrote:
> Just an FYI:
> I'm sure you meant to sincerely thank Robert, but the above reads like you are blaming him for it being harder to do than to complain. "Thanks to you" is dangerous to put near anything negative as it's just a commonly used sarcastically as it is sincerely. English is weird :)

Thanks for the heads up, that is indeed what I meant.