I've just fixed UFCS for the experimental type function branch

[Bruce Carneal]

On Thursday, 10 September 2020 at 16:52:12 UTC, H. S. Teoh wrote:
> On Thu, Sep 10, 2020 at 04:28:46PM +0000, Bruce Carneal via 
> Digitalmars-d wrote:
>> On Thursday, 10 September 2020 at 15:14:00 UTC, Per Nordlöw 
>> wrote:
>> > On Thursday, 10 September 2020 at 09:43:34 UTC, Stefan Koch 
>> > wrote:
>> > > limited UFCS for type functions works again.
>> > 
>> > Having type functions with UFCS is a significant improvement 
>> > of the developer experience aswell compared to having to use 
>> > templates.
>> 
>> Absolutely.  Functions are more readable, compose more 
>> readily, are easier to debug (better locality), and tickle 
>> fewer compiler problems than templates.  CTFE is a huge win 
>> overall, "it just works".
>
> I wouldn't be so sure about that last part. The current CTFE 
> implementation is, shall we say, hackish at best? ...

When I said "it just works" I should have said "it just works as 
you'd expect any program to work".  The implementation may be 
lacking but the contract with the programmer is wonderfully 
straightforward.

> It "works" by operating on AST nodes as if they were values, 
> and is slow, memory inefficient, and when there are problems, 
> it's a nightmare to debug. For small bits of code, it works 
> wonderfully, but ...

Yes.  My understanding is that the current implementation is much 
less than ideal for both but that we may be able to clear away a 
lot of the template "problem" in one go with type functions.  
Crucially, the type function implementation complexity is, 
reportedly, much much lower than that seen in other sub 
components.

>
>
>> By contrast, when using D's pattern matching meta programming 
>> sub-language, things start out very nicely but <... rapidly 
>> degenerate>
>
> To be fair, the problems really only arise with IFTI and a few 
> other isolated places in D's template system.  In other 
> respects, D templates are wonderfully nice to work with.  
> Definitely a refreshing change from the horror show that is C++ 
> templates.

Yes.  Of course in theory D templates are no more powerful than 
C++ templates but anyone who has used both understands that 
simplicity in practical use trumps theoretical equivalence.  As 
you note, it's not even close.

It seems to me from forum postings and reports on the 
(un)maintainability and instability of large template heavy dlang 
code bases, that we're approaching the practical limits of our 
template capability.  At least we're approaching the "heroic 
efforts may be needed ongoing" threshold.

So, what to do?  We can always add more tooling to try and help 
the situation: better error reporting, better logging, pattern 
resolution dependency graph visualizers, ...

We can also go the "intrinsics" route: "have something that's too 
hard to do with templates?  No problem, we'll add an intrinsic!".

We can also go the template library route: "too tough for mere 
mortals?  No problem, my super-duper layer of template magic will 
make it all better!".

You'll note that not one of the above "solutions" actually 
reduces complexity, they just try to manage it.  Type functions, 
on the other hand, look like they would support real world 
simplification.  Much of that simplification comes from 
programmer familiarity and from the ability to "opt-in" to 
pattern/set operations rather than being forced to, awkwardly, 
opt-out.

>
>
>> In a type function world we'll still need templates, we'll 
>> just need fewer of them.
>
> Generally, I'm in favor of this. Templates have their place, 
> but in many type manipulation operations, type functions are 
> definitely better than truckloads of recursive template 
> instantiations with their associated memory hoggage and 
> slowdown of compile times.

Yep.