January 10, 2014
The current state of Phobos documentation is terrible in some moments. Many types and functions are not described how to use. For example, from documentation I don't know how to use ErrnoException. Does it have field for error code copied from errno, or should I use errno directly when I meet this exception? What message does ErrnoException provide? It's from stderror function or some dependent on caller? Plenty of questions arise when you need to know how do class or function work, and you often need to browse source code to find out what happens. But ideally documentation must be full, so user does not have to look into sources.

There is also sensible lack of examples. Look at std.encoding. Well, actually I'm sure that the whole module needs to be rewritten, I don't see any benefits of "templated" approach to work with encoding.
Other thing is "auto" as returned type. It's very handy in code, but I think library documentation should mark returned types more explicitly.
So there is many work on Phobos documentation to make it better.

Also there are some deprecated modules needed for replacement, for example, std.stream and std.socketstream (but I'm not sure why). I believe streams are important to ease programming, but they need really good interface and implementation (flexible and extensible), maybe you have some ideas on it.
January 10, 2014
>- Make DCD plugins for editors so they can autocomplete, go to
definition
+1
January 10, 2014
On 2014-01-10 12:36, FreeSlave wrote:
> The current state of Phobos documentation is terrible in some moments.
> Many types and functions are not described how to use. For example, from
> documentation I don't know how to use ErrnoException. Does it have field
> for error code copied from errno, or should I use errno directly when I
> meet this exception? What message does ErrnoException provide? It's from
> stderror function or some dependent on caller? Plenty of questions arise
> when you need to know how do class or function work, and you often need
> to browse source code to find out what happens. But ideally
> documentation must be full, so user does not have to look into sources.

I agree.

> There is also sensible lack of examples. Look at std.encoding. Well,
> actually I'm sure that the whole module needs to be rewritten, I don't
> see any benefits of "templated" approach to work with encoding.
> Other thing is "auto" as returned type. It's very handy in code, but I
> think library documentation should mark returned types more explicitly.
> So there is many work on Phobos documentation to make it better.

Ddoc needs to resolve "auto" to the actual type.

> Also there are some deprecated modules needed for replacement, for
> example, std.stream and std.socketstream (but I'm not sure why). I
> believe streams are important to ease programming, but they need really
> good interface and implementation (flexible and extensible), maybe you
> have some ideas on it.

I think they need to be able to work with ranges.

-- 
/Jacob Carlborg
January 10, 2014
On 1/10/14 3:36 AM, FreeSlave wrote:
> The current state of Phobos documentation is terrible in some moments.

Agreed. Please submit bug reports for it. This is one area in which literally every member of the community can contribute.

Andrei
January 10, 2014
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:
>
> So, what I actually wanted to ask, which part/project do you think mostly needs contribution? The D documentation on this page? Mono-D (I’ll be using that, already contributed to an issue)? DUB? vibe.d and its documentation? More tutorials on a seperate blog?

I'm going to answer with a question of my own.  What requirement
for your project do you feel is most lacking in D right now?  I'd
work on that, since you would have the best idea of what the
result should be and the greatest motivation to get it done.  Or
if there's nothing lacking, some tutorials would be awesome.
January 10, 2014
On Friday, 10 January 2014 at 14:02:16 UTC, Jacob Carlborg wrote:
> On 2014-01-10 12:36, FreeSlave wrote:
>> The current state of Phobos documentation is terrible in some moments.
>> Many types and functions are not described how to use. For example, from
>> documentation I don't know how to use ErrnoException. Does it have field
>> for error code copied from errno, or should I use errno directly when I
>> meet this exception? What message does ErrnoException provide? It's from
>> stderror function or some dependent on caller? Plenty of questions arise
>> when you need to know how do class or function work, and you often need
>> to browse source code to find out what happens. But ideally
>> documentation must be full, so user does not have to look into sources.
>
> I agree.
>
>> There is also sensible lack of examples. Look at std.encoding. Well,
>> actually I'm sure that the whole module needs to be rewritten, I don't
>> see any benefits of "templated" approach to work with encoding.
>> Other thing is "auto" as returned type. It's very handy in code, but I
>> think library documentation should mark returned types more explicitly.
>> So there is many work on Phobos documentation to make it better.
>
> Ddoc needs to resolve "auto" to the actual type.
>

Unless it's a voldemort type.

January 10, 2014
On 2014-01-10 20:36, Brad Anderson wrote:

> Unless it's a voldemort type.

Now this becomes a bit tricky ;)

-- 
/Jacob Carlborg
1 2
Next ›   Last »