On Friday, 4 October 2013 at 13:30:39 UTC, Jacob Carlborg wrote:
> On 2013-10-04 12:17, Dicebot wrote:
>> I liked the proposal to add special `dub` category for those (`dub`
>> needs some categorization anyway). Only drawback is that it actually
>> needs to be implemented instead of simply making a decision :)
>
> For that, dub needs to be bundled with DMD.

Why? As long as the installation process is simple enough, I don't see a big problem with pointing users to an extra tool for access to ${favorite_awesome_library}.

David

On Saturday, 5 October 2013 at 14:46:49 UTC, David Nadlinger wrote:
> Why? As long as the installation process is simple enough, I don't see a big problem with pointing users to an extra tool for access to ${favorite_awesome_library}.

(That being said, I think we should indeed try to offer batteries-included packages for people to jump into D development.)

On 10/04/2013 12:02 PM, John Colvin wrote:
> Adding new (or replacement) phobos modules without wider testing is
> not a scalable approach for D.
> New modules go from unofficial to official in a single step and are
> therefore inadequately battle-tested before becoming part of the
> somewhat ossified environment of a standard library.
>
I don't think that this is a good idea. Just consider linux pre and post 2.6. Pre, the % 2 == 1 branches took forever and now they have more changes than ever and put out multiple release per year (I know we're not linux, yet). I also would consider stdx as some sort of dead end for code, like "it's ok, but not phobos worthy".

On 2013-10-05 16:46, David Nadlinger wrote:

> Why? As long as the installation process is simple enough, I don't see a
> big problem with pointing users to an extra tool for access to
> ${favorite_awesome_library}.

I just don't think it would be really official.

-- 
/Jacob Carlborg

On 04/10/13 12:02, John Colvin wrote:
> I propose that the current review process be redirected to a new target package
> in the phobos repo, stdx, which would then have a separate review process for
> inclusion in std.

Just a thought after reading through the discussion on std.d.lexer, but -- isn't this what etc library modules are for?

See: http://dlang.org/phobos/index.html

-----------------------------------------------------------------------------------
etc
    This is the root of a hierarchy of modules mirroring the std hierarchy.
    Modules in etc are not standard D modules. They are here because they are
    experimental, or for some other reason are not quite suitable for std,
    although they are still useful.
-----------------------------------------------------------------------------------

On Sunday, 6 October 2013 at 16:33:24 UTC, Joseph Rushton Wakeling wrote:
> On 04/10/13 12:02, John Colvin wrote:
>> I propose that the current review process be redirected to a new target package
>> in the phobos repo, stdx, which would then have a separate review process for
>> inclusion in std.
>
> Just a thought after reading through the discussion on std.d.lexer, but -- isn't this what etc library modules are for?
>
> See: http://dlang.org/phobos/index.html
>
> -----------------------------------------------------------------------------------
> etc
>     This is the root of a hierarchy of modules mirroring the std hierarchy.
>     Modules in etc are not standard D modules. They are here because they are
>     experimental, or for some other reason are not quite suitable for std,
>     although they are still useful.
> -----------------------------------------------------------------------------------

I like the idea of dub.stdx: peer-reviewed, officially endorsed and rubber stamped modules

 * It provides a BOOST like repository of high quality peer-reviewed D libraries.

 * It decouples the modules from the Phobos+compiler release schedule.

 * It allows users to download official libraries individually, without upgrading compiler/Phobos or using git head.

 * It provides a place official D libraries too big for Phobos. I'm thinking of a Matlab toolbox type of repository with high quality code. 3D/2D Gfx, GUI, image processing libraries, linear-algebra, machine learning libraries etc. etc.

 * Dub might be able to collect stats on downloads per module and provide information about the popularity and amount of real-world use a module receives before proposing for Phobos.std.

Cheers

On Friday, 4 October 2013 at 10:02:21 UTC, John Colvin wrote:
> I propose that the current review process be redirected to a new target package in the phobos repo, stdx, which would then have a separate review process for inclusion in std.

not good. stdx is the same trap as javax: throw-away that never gets thown away and sticks around until forever.

better is to include it in std with a big pragma that warns at compilation time about its instability (a kind of staging... stage)

warnings about interface/behavior changes should be issued with every new release of the module *in code* (and in doc, of course)

old interfaces could be or could not be not kept with deperecation pragmas

in the medium/long term, pragmas will get removed progressively

On Friday, 4 October 2013 at 10:49:58 UTC, John Colvin wrote:
> The lack of promise of API stability in stdx would have to be very explicit and obvious.

Then call it `experimental` instead of stdx. That's obvious (stdx sound like an extension of std library). I wonder if someone would complain that experimental module broke.

On Monday, 7 October 2013 at 15:36:23 UTC, Kagamin wrote:
> On Friday, 4 October 2013 at 10:49:58 UTC, John Colvin wrote:
> Then call it `experimental` instead of stdx. That's obvious (stdx sound like an extension of std library). I wonder if someone would complain that experimental module broke.

if nobody complains, then experimental would be useless: code could go directly into std.

On Monday, 7 October 2013 at 08:20:20 UTC, eles wrote:
> not good. stdx is the same trap as javax: throw-away that never gets thown away and sticks around until forever.

That's just a matter of enforcing the policy. The only problem I see is that stdx can be good enough to be an excuse for not having the feature in phobos.