syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

[Andrei Alexandrescu via Digitalmars-d]

On 02/22/2017 06:53 AM, Atila Neves wrote:
> On Thursday, 16 February 2017 at 13:21:04 UTC, Andrei Alexandrescu wrote:
>> On 2/16/17 7:11 AM, Atila Neves wrote:
>>> 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.
>>>
>>> I submitted a Phobos PR for `isInputRangeOf`. It was nuked from orbit. I
>>> understand why: as you mention, the combinatorial explosion of names is
>>> an issue. But: it's a mess rangeifying code when this:
>>>
>>> void fun(Foo[] foos);  // yay! readable
>>>
>>> becomes:
>>>
>>> void fun(R)(R foos) if(isInputRange!R && is(Unqual!(ElementType!R) ==
>>> Foo);
>>
>> If you find a number of these, that would be good evidence. -- Andrei
>
> I found just over 70 similar lines, which is more than I expected given
> how generic Phobos is. The real issue is in client code though. I write
> less range-based code than I'd like, because it's a lot easier to make
> it a regular array and change it later if the function needs to be
> called with other ranges.

If you submit a pull request that simplifies >70 constraints in Phobos 
and implicitly promises to simplify client-level constraints as much, 
that would have a good chance to be accepted. Destroy! -- Andrei