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

[Andrei Alexandrescu via Digitalmars-d]

On 02/14/2017 10:49 AM, Jacob Carlborg wrote:
> On 2017-02-14 15:37, Andrei Alexandrescu wrote:
>
>> How are they so,
>
> Example [1]. That signature spans 8 lines, it took me 10 seconds to find
> the actual function name.

Copying here to make things easier:

Range remove
(SwapStrategy s = SwapStrategy.stable, Range, Offset...)
(Range range, Offset offset)
if (s != SwapStrategy.stable
     && isBidirectionalRange!Range
     && hasLvalueElements!Range
     && hasLength!Range
     && Offset.length >= 1);

The function name is on the first line. I think 10 seconds would be an 
exaggeration of an admittedly real issue.

> Example [2], 5 lines.

Copying here as well (reflowed for email):

Tuple!(InputRange1, InputRange2)
swapRanges(InputRange1, InputRange2)(InputRange1 r1, InputRange2 r2)
if (isInputRange!(InputRange1) && isInputRange!(InputRange2)
     && hasSwappableElements!(InputRange1)
     && hasSwappableElements!(InputRange2)
     && is(ElementType!(InputRange1) == ElementType!(InputRange2)));

One immediate matter here is redundant parens, of which elimination 
would lead to the marginally more palatable:

Tuple!(InputRange1, InputRange2)
swapRanges(InputRange1, InputRange2)(InputRange1 r1, InputRange2 r2)
if (isInputRange!InputRange1 && isInputRange!InputRange2
     && hasSwappableElements!InputRange1
     && hasSwappableElements!InputRange2
     && is(ElementType!InputRange1 == ElementType!InputRange2));

>> and what steps can we take to improve them. Could you
>> please give a few examples on how to do things better? Thx! -- Andrei
>
> Well, I would prefer to have template constraints as its own entity in
> the language not not just a bunch of boolean conditions. This has been
> talked about before several times. Something like:
>
> constraint Foo
> {
>     void foo();
> }
>
> void bar(T : Foo)(T t);

My recollection is past discussions got stalled because the approach is 
combinatorially bankrupt. How would one express the constraints of the 
functions above with simple named constraints? (Not rhetorical; please 
do provide an example if possible.) Before long there is an explosion in 
names ("BidirectionalWithLvalueElementsAndLength", ...). This is what 
has buried not one, but two concepts proposals for C++, leading to the 
current Concepts Lite proposal. I haven't followed that lately but I 
remember it combines an engineering effort to reduce the number of names 
introduced (for the standard library only, which is a limitation) with 
adding support to Boolean logic (surprise, surprise) to the feature (see 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf), the 
most recent proposal, which was rejected for C++17. Over time, C++ 
concepts have moved from the broken combinatorially-bankrupt form slowly 
toward D's Boolean constraints (just with a gratuitously awkward 
notation). I presume they will be merged into the language when they'll 
have capabilities comparable to D's system.

The question is, given this experience, do we want to move the opposite 
direction?


Andrei