Now that's a DIP that could use some love

jmh530 john.michael.hall at
Thu Sep 17 23:10:23 UTC 2020

On Thursday, 17 September 2020 at 22:29:50 UTC, jmh530 wrote:
> On Thursday, 17 September 2020 at 21:55:22 UTC, Andrei 
> Alexandrescu wrote:
>> [snip]
> I don't think the people who disagree and instead think that 
> the situation is good. HS Teoh recommended an alternative 
> approach that may provide simpler error reports. His approach 
> would effectively widen the template constraints to something 
> like just isInputRange. One could still make an argument about 
> isInputRange not provided valuable error reporting, but that is 
> one thing that Atila's concepts library attempts to fix.

I also want to draw some attention to another possible solution 
to this morass, which is enhancing template alias deduction. 
Someone was working on a DIP for this, but their approach became 
tricky in the more general case. Ideally something like below 
could work where the call to foo(y) would produce the result from 
the static assert. In other words, instantiating foo with T 
should cause ArrayType(T) to be instantiated, which could either 
produce the relevant alias that would be used for deduction or 
the result of the static assert appears before any additional 
matching would go on.

A similar template alias for InputRange (instead of isInputRange) 
would basically return the type if it passes the relevant checks 
and a detailed error message otherwise.

I would think this would somehow fit in with Stefan Koch's work 
on type/alias functions...

template ArrayType(T)
     import std.traits: isDynamicArray;
     static if (isDynamicArray!T) {
         alias ArrayType = T;
     } else {
         static assert(0, "T is not a valid ArrayType");

void foo(T)(ArrayType!T x) {

void main()
     int[] x;
     foo(x); //does not currently compile
     int y;
     foo(y); //does not currently compile, shouldn't compile

More information about the Digitalmars-d mailing list