On Tuesday, 14 February 2017 at 22:01:47 UTC, H. S. Teoh wrote:
> Thankfully, the docs for std.conv.to have been greatly improved since the last time I had to work with the code -- everything is now consolidated under a single template function std.conv.to, and the implementation details are hidden behind module-private overloads. This is the way it should be.

I'm currently trying to do this again in std.format, this is the first step: https://github.com/dlang/phobos/pull/5130

On Wednesday, 15 February 2017 at 08:53:30 UTC, Jacob Carlborg wrote:
> "The static if feature recently proposed for C++ [1, 2] is fundamentally flawed, and its adoption would be a disaster for the language" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf

I honestly feel bad for the C++ people here. Looks like someone didn't explain the benefits/uses of static if very well.

It also looks like they failed to point to Phobos as an example of great static if usage. I imagine many heads would explode after seeing Andrei's `find` improvements with static if.

On Wednesday, 15 February 2017 at 14:01:28 UTC, Andrei Alexandrescu wrote:
> It still has a cargo cult flavor because it introduces a new scope, which kinda misses the point of static if.

That's an understatement.

Having static if introduce a new scope makes static if useless. Creating a new scope means that code duplication inside of a function is now a must. At that point you might as well just make what you were going to put in the other static if branch as a different overload.

It also means design by introspection/range composition is now impossible.

On Wednesday, February 15, 2017 14:35:40 Jack Stouffer via Digitalmars-d wrote:
> On Wednesday, 15 February 2017 at 08:53:30 UTC, Jacob Carlborg
>
> wrote:
> > "The static if feature recently proposed for C++ [1, 2] is fundamentally flawed, and its adoption would be a disaster for the language" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf
>
> I honestly feel bad for the C++ people here. Looks like someone didn't explain the benefits/uses of static if very well.
>
> It also looks like they failed to point to Phobos as an example of great static if usage. I imagine many heads would explode after seeing Andrei's `find` improvements with static if.

LOL. It would be interesting to know which parts of D or Phobos blew people's minds. Personally, startsWith blew my mind. I remember taking up the challenge of making endsWith work with all of the same kind of arguments that startsWith did, and at the time, I had no idea how startsWith was implemented. Seeing how it used recursive template instantiations definitely took a bit to wrap my mind around and was _very_ eye opening.

- Jonathan M Davis

On Wed, 15 Feb 2017 05:28:11 +0000, Adam D. Ruppe wrote:

> On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote:
>> A further improvement in the documentation would be to add links to isBidirectionalRange and hasLvalueElements.
> 
> Kneel before your god!

We're not worthy!

On Wed, 15 Feb 2017 08:56:00 +0100, Jacob Carlborg wrote:
> Your documentation is an improvement but it doesn't help when reading the source code.

For me, it almost entirely obviates reading the source code. I only need to read it if I'm trying to modify it, at which point I'm already committing to spend at least thirty minutes on it.

The greatest annoyance is if I have to read through several files of phobos sources just to figure out why there's no matching overload for this function call that looks right to me. This doc improvement means I only have to go to dpldocs.info (which I'm probably already at), search for the term, and click a few times. I don't have to pull out grep, peer myopically through the pages of results, and figure out which ones are the definitions of the template constraints I need.

On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote:
> Your documentation is an improvement but it doesn't help when reading the source code.

Yeah, I think there's a few things we can do in the source too. We should find the common combinations and abstract them out, like I said before, isInputRangeOf is potentially useful.

Though, like Andrei, I'm skeptical on doing too much of that, since the combinations can quickly explode and then you just have to search through more to figure out wtf they mean.

That'd help the source and docs if we find the right balance.

On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote:
> On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote:
>> Your documentation is an improvement but it doesn't help when reading the source code.
>
> Yeah, I think there's a few things we can do in the source too. We should find the common combinations and abstract them out, like I said before, isInputRangeOf is potentially useful.
>
> Though, like Andrei, I'm skeptical on doing too much of that, since the combinations can quickly explode and then you just have to search through more to figure out wtf they mean.
>
> That'd help the source and docs if we find the right balance.

Speaking of right balance, there's currently a PR at Phobos that is a good candidate to get a common measure on how this balance should be set:

https://github.com/dlang/phobos/pull/5132

The open question here is that for nearly every function in std.file & std.path the constraint block looks like this:

uint getAttributes(R)(R name)
if (isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R);


Now as this same block is used > 30x in Phobos one could argue that it makes sense to use a convenience trait like:

enum isSomeInputRangeChar(R) = isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R

which would obviously lead to:

uint getAttributes(R)(R name)
if (isSomeInputRangeChar!R)

What's your opinion on such a case?

On Wednesday, 15 February 2017 at 16:20:30 UTC, Chris Wright wrote:
> The greatest annoyance is if I have to read through several files of phobos sources just to figure out why there's no matching overload for this function call that looks right to me.

I really really REALLY REALLY wish the compiler would tell you at least which part of the boolean expression failed. Then, at least, you could dig deeper with your own static asserts on those individual things or something.

tbh I actually want opt-in XML error messages with obscene levels of detail. We'd pwn IDE integration with that and can really save programmers wads of time by giving them all the info they actually need.

D used to promote its readable error messages as a strength over C++. We've fallen far behind in that category now.

 This doc improvement means I only have to go to
> dpldocs.info (which I'm probably already at), search for the term, and click a few times.

indeed, I'm pretty happy with my navigation. And I'm slowly but surely fixing the automatic cross referencing. D name lookup across modules is kinda hard, this is one place dmd/ddoc would have a strong theoretical advantage since it understands the semantics and already knows the module graph.

But, I'm already 80% there... and it is yielding pretty great results in practice. I'll do alias lookups next time I spend a few hours on this (tbh since it is good enough for me, it is all low priority relative to the other things I have to do, so it is moving slowly now.)

On Wednesday, 15 February 2017 at 17:18:15 UTC, Seb wrote:
> Now as this same block is used > 30x in Phobos

That tells me you already have an empirical clear win! If you wrote exactly the same thing 30x inside the functions, you'd move it out to a new function too.

> if (isSomeInputRangeChar!R)
>
> What's your opinion on such a case?

Yeah, I'd say do it, and it is similar to isSomeString in use elsewhere.