On 1/26/15 11:48 AM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Jan 26, 2015 at 10:33:32AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote:
> [...]
>>> 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. Whatever happened to incremental
>>> refinement??  Do we really expect flawless perfection before merging
>>> to, of all places, std.*experimental*?
>>
>> For a good while there was no std.experimental. Its introduction was
>> partially motivated by the stalemate of this contribution. -- Andrei
>
> And yet it still took so long to get it in?
>
> IMO a better approach would have been, merge it into std.experimental
> sooner, then submit followup PRs to std.experimental when the
> implementation is found to be inferior.

Of course. I repeat: for a long time std.experimental was not an option. Clearly it's better with it than without, and merging into std.experimental first, std later, will be the way we roll. -- Andrei

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.

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

On Mon, Jan 26, 2015 at 08:30:58PM +0000, Dicebot via Digitalmars-d 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.

Yeah, this part didn't make much sense to me. While I agree that we shouldn't be accepting random junk into std.experimental, the bar shouldn't be set so high that legitimate initial revisions of a new module are also excluded. Otherwise, what's the point of even having std.experimental as opposed to merging straight into std?


> 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.

+1.

And we should not forget that if something in std.experimental continues to disappoint, there's always the option of dropping it altogether, since we don't guarantee non-breakage on std.experimental. So there's no reason the bar should be as high as it is right now.


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying

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

That was.. unexpected :) Does that mean requirements for any future experimental proposals should also be tuned down a bit?

On 1/26/15 12:46 PM, Dicebot 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
>
> That was.. unexpected :) Does that mean requirements for any future
> experimental proposals should also be tuned down a bit?

Of course. I'm not planning to repeat the mistake :o). -- Andrei

On Monday, 26 January 2015 at 20:51:40 UTC, Andrei Alexandrescu wrote:
>> That was.. unexpected :) Does that mean requirements for any future
>> experimental proposals should also be tuned down a bit?
>
> Of course. I'm not planning to repeat the mistake :o). -- Andrei

Great news, thanks!

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

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

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?

On Monday, 26 January 2015 at 18:19:18 UTC, H. S. Teoh wrote:
> 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. Whatever happened to incremental
> refinement??  Do we really expect flawless perfection before merging to,
> of all places, std.*experimental*?
>
>
> T

This is what I was thinking this morning.... I saw something about logger review and and thought to myself "this is still going on?"