Developing a plan for D2.0: Getting everything on the table

[Benji Smith]

Andrei Alexandrescu wrote:
> Benji Smith wrote:
> Maybe if Andrei put together a list of 
>> missing Phobos functionality, we could get people from the community 
>> to flesh out the libs.
> 
> I think we'd need at a minimum:

<snip>

> That would be great. In general, it would be awesome to gather more 
> contributions from the community. There's a thirst to contribute and 
> we'll be glad to involve this group into some serious design e.g. for 
> concurrency support, as well as accept code for functionality that 
> belongs to the standard library.
> 
> In the bulleted list above there are many mini-projects that are 
> confined enough to be done by one willing individual in a relatively 
> short time.

Are there contributor guidelines somewhere?

For example, should the author of a container library prefer classes or 
structs? Should other (non-container) modules accept container classes 
as arguments? Or only container interfaces (if there are any such 
things) or just ranges?

Is it appropriate to use an empty struct purely as a namespace for the 
introduction of free functions? Or should free functions be placed at 
the module level?

Is it appropriate to define multiple classes, structs, templates, etc 
within a single module? What considerations should inform the decision 
regarding the placement of module boundaries?

What constitutes appropriate/inappropriate usage of opCall?

Anyhoo...

Point being, Phobos_1 was a hodgepodge of different conventions and 
styles. Tango_1 was considerably better, in terms of stylistic 
uniformity. But it used a very different set of idioms than Phobos_1 
(lots of predicate functions, "sink" delegates, etc). Probably any 
author contributing code to Phobos_2 should spend a little time getting 
up to speed with the preferred idioms before writing code.

I suspect that my humble little JSON parser uses styles and idioms that 
would clash with the majority of Phobos_2 (since my programming pedigree 
comes from Java, C#, JavaScript, and Perl much moreso than C or C++).

--benji