++Phobos

[rikki cattermole]

On 17/10/2019 4:32 PM, Jesse Phillips wrote:
> On Thursday, 17 October 2019 at 00:46:12 UTC, rikki cattermole wrote:
>>
>> I.e.
>>
>> signature InputRange(@named ElementType = 
>> ElementTypeCompat!(typeof(this)) { ... }
>>
>> Not to mention it forces what amounts to idiomatic D into a second 
>> class position in many use cases. Not preferable IMO.
> 
> auto foo(R, E = ElementType!R)() if(implements!(InputRange!E, R))
> 
> That seems pretty idiomatic D.

And that's the problem, for what is very common, it is absolutely 
horrible code.

> Now as you said, it doesn't improve the error message. But what if the 
> language changed so it could?

That would require flow analysis and it won't give good names to 
different aspects.

We have done research into template constraints and to improve the error 
messages there. But aggregate checks like isInputRange and with that 
implements, the compiler can't understand it even with flow analysis sadly.

Right now there is no way to communicate to the compiler the human 
aspects of a concept. Sure we can do the technical, but that only gets 
us so far (which we have been doing).

This is what I am arguing for, a way to communicate to the compiler the 
human aspects of a concept. The behaviors and properties it must exhibit 
to match our mental model, not the compilers model.