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

[Andrei Alexandrescu]

Benji Smith wrote:
> 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?

Not at the moment.

> For example, should the author of a container library prefer classes or 
> structs?

I've been struggling with this forever. I don't know. I don't even know 
whether reference or value semantics are best for containers. I don't 
know whether abstract container interfaces and container-independent 
code are a net win; experience with STL seems to say "don't" and 
experience with Java seems to say "ho-hum".

> Should other (non-container) modules accept container classes 
> as arguments? Or only container interfaces (if there are any such 
> things) or just ranges?

I think ranges should be preferred wherever applicable.

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

I think module-level functions are best. If there are lookup issues due 
to that, we need to fix the language. D is conceived to allow proper 
coexistence of functions in different modules without forcing the user 
to take too many precautions.

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

I think it's appropriate because many pieces of functionality come as a 
bundle. The rule of thumb is, module provides the functionality, and 
it's up to the designer to decide what that entails.

> What constitutes appropriate/inappropriate usage of opCall?

What examples do you have in mind?

> 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 agree. I am obviously subjective, but here are a few modules in 
phobos2 that seem to me close to the desired look and feel:

* std.algorithm is a large collection of functions mostly operating on 
one abstraction (ranges). If you know how to use one algorithm, you 
probably know how to use all others. Defining ranges that std.algorithm 
can work with is also a breeze.

* std.getopt is a very effective module. Although it does a fair amount 
of stuff, it has a simple interface that can be learned in minutes. I 
haven't seen an options parsing library that has the same power/ease 
ratio. Its usage of static types to infer what you want to do is a good 
showcase for the power of D templates and variadics.

* std.conv is simple (in interface), convenient, and general.

* std.range could use some maturing. I'm currently not 100% pleased 
about it.

* std.file looks a bit quaint (e.g. no classes) but I'm comfortable 
around it. It does what it's supposed to do and does it well.

* std.numeric is an example of a library that has a mix of functions and 
objects collected under an umbrella topic. I'm ok with it, but at some 
point I suspect I'd start worrying about its growth. Same about e.g. 
std.typecons.

* std.md5 is an example on why it's not that advisable to just copy a C 
interface into D. (This is a negative example.)

* std.random is a simple, extensible design, and has convenience 
functions  (such as uniform) that are, well, darn convenient. I see it 
growing easily and nicely.

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

Phobos2 doesn't have (m)any hierarchies not because Walter or I don't 
use them or like them. It's just that the particular stuff that's in 
Phobos right now is at an advantage by using other design means. But if 
you come with a good hierarchy implementing a piece of functionality, great.


Andrei