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

[Jacob Carlborg via Digitalmars-d]

On 2017-02-14 17:25, Andrei Alexandrescu wrote:

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

It would obviously take a while for me to figure that out. Is not like I 
have a fully defined new language feature in my head.

I do see a possibility for a slightly improvement in a different area, 
in the example of "remove". If we look at the signature, without the 
constraints:

Range remove
(SwapStrategy s = SwapStrategy.stable, Range, Offset...)
(Range range, Offset offset)

Why isn't it possible to use "auto" when declaring a parameter with a 
default argument?

Range remove
(auto s = SwapStrategy.stable, Range, Offset...)
(Range range, Offset offset)

A minor improvement, but I also feel like it would lift an arbitrary 
limitation in the language.

Alternatively something that Swift supports:

Range remove
(SwapStrategy s = .stable, Range, Offset...)
(Range range, Offset offset)

The compiler knows that the type of "s" is SwapStrategy, therefore 
"stable" has to be a member of SwapStrategy. In the case of D, the 
leading dot has a different meaning so another syntax would be required. 
Unfortunately this has already been discussed and rejected by Walter.

> 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 don't see that as a problem, but I would rather name it "Removable" or 
something that does not include all the conditions in the name. But I 
imagine that a constraint would consist of a combination of declarations 
(like an interface) and boolean conditions.

Lets look it differently. For a regular (non-template) function with a 
user defined type (class, struct). If it was possible to define the type 
inline, would you? I hope that answer is no. Example:

Standard D:

struct Bar
{
     int a;
     int b;
}

void foo(Bar bar);

With inline user defined types:

void foo(struct { int a; int b; } bar);

Assuming the answer is no, why would it be any different for a template 
type? You can see all the template constraints for a type as a form of 
metatype.

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

I haven't followed the C++ concepts lately either and not very closely 
at all so I don't feel I can comment on the C++ concepts. But if I 
recall correctly, you're "static if" proposal wasn't well received [1]. 
But now with "if constexpr" it looks like they're changing their minds.

[1] "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

-- 
/Jacob Carlborg