• Stefan Koch (16/16) Sep 30 2020 It just came to me.
• Stefan Koch (26/43) Sep 30 2020 Actually.
• FeepingCreature (12/24) Oct 01 2020 Yep.
• H. S. Teoh (18/30) Oct 01 2020 This. I've spent who knows how many hours trying to decipher template
• jmh530 (4/8) Oct 01 2020 It's a little unclear to me what you are talking about, but my

Stefan Koch <uplink.coder googlemail.com> writes:

It just came to me.
I know how to fix the user-visible problems of templates now.
How to make them debuggable.
Sadly this only benefits the programmer and not the compiler, 
since the compilers problems come from static polymorphism mostly.

But for the usage of templates we can fix the soup of if 
constraints and trying to find which overload should have been 
picked.

I must have been blind.
Shame about there not being a compiler speedup potential in it.

But at least I can now have hope  of being able to debug template 
based code in the future.
This time however there won't be sneak previews.

I won't make the same mistake twice.

Cheers,

Stefan

Stefan Koch <uplink.coder gmail.com> writes:

On Thursday, 1 October 2020 at 03:27:45 UTC, Stefan Koch wrote:
 It just came to me.
 I know how to fix the user-visible problems of templates now.
 How to make them debuggable.
 Sadly this only benefits the programmer and not the compiler, 
 since the compilers problems come from static polymorphism 
 mostly.

 But for the usage of templates we can fix the soup of if 
 constraints and trying to find which overload should have been 
 picked.

 I must have been blind.
 Shame about there not being a compiler speedup potential in it.

 But at least I can now have hope  of being able to debug 
 template based code in the future.
 This time however there won't be sneak previews.

 I won't make the same mistake twice.

 Cheers,

 Stefan

Actually.
I just realized I don't care about implementing this at all.
And the idea isn't all that revolutionary ...
So I might as well flesh it out here.

The reason why templates are so bad at being composable, is 
because template constraints don't compose.

when a template T with constraints(C) yields an valid instance, 
that proofs the constraints hold.
which implies that for anything using an instance of T the 
constraints C also hold.

When we compose functions our constraints are coupled to types.
Because templates themselves are (or can be) untyped in both 
Parameters and "return value".
We can't use those to carry the constraints forward.

Leading us into a case where we have to repeat the same 
constraints over and over again.

That means all we need to do, is to group constraints (I believe 
this is what C++ calls concepts? I am not sure about this, 
perhaps Andrei or Atila could clarify)

I can imagine a nice implementation of this, but since it doesn't 
solve the performance problem, I am not interested.

I guess a fully polymorphic version of type functions, which is 
by then an implementation first class types, would fix that.

But again polymorphism is exactly what I want to avoid.

Because once things are polymorphic how do you predict the shape?

FeepingCreature <feepingcreature gmail.com> writes:

On Thursday, 1 October 2020 at 05:23:51 UTC, Stefan Koch wrote:
 The reason why templates are so bad at being composable, is 
 because template constraints don't compose.

 when a template T with constraints(C) yields an valid instance, 
 that proofs the constraints hold.
 which implies that for anything using an instance of T the 
 constraints C also hold.

 When we compose functions our constraints are coupled to types.
 Because templates themselves are (or can be) untyped in both 
 Parameters and "return value".
 We can't use those to carry the constraints forward.

 Leading us into a case where we have to repeat the same 
 constraints over and over again.

Yep.

Right now, constraints are carried forward invisibly through 
gagged template instantiation via __traits(compiles). 
Miscompilation *itself* becomes the propagated constraint 
failure, which is of course horrible.

This is why I want __traits(canInstantiate), so we can at least 
*enforce* that constraints are manually carried forward by the 
programmer. If a template passes its constraints, it should also 
pass semantic2/3 in full. It should never be necessary to gag 
errors after the constraints.

Body SFINAE is cancer.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Oct 01, 2020 at 07:39:04AM +0000, FeepingCreature via Digitalmars-d
wrote:
[...]
 Right now, constraints are carried forward invisibly through gagged
 template instantiation via __traits(compiles). Miscompilation *itself*
 becomes the propagated constraint failure, which is of course
 horrible.
 
 This is why I want __traits(canInstantiate), so we can at least
 *enforce* that constraints are manually carried forward by the
 programmer. If a template passes its constraints, it should also pass
 semantic2/3 in full. It should never be necessary to gag errors after
 the constraints.
 
 Body SFINAE is cancer.

This.  I've spent who knows how many hours trying to decipher template
errors precisely because a single misspelled identifier in the wrong
place can completely change the chain of template instantiations,
leading to a completely unrelated failure in a completely unrelated part
of the code, with the original real error gagged so there is almost no
clue is to what the problem really is.

I wish there were a better mechanism of deferring to a different
template besides all-out error gagging regardless of the nature of the
error.  It's one thing to try a different overload when sig constraints
fail; it's a whole 'nother can o' worms when sig constraints pass but a
typo causes the body to fail.  The worst is when this was triggered from
within another function's sig constraints -- then you really have almost
no way to trace the source of the error.


T

-- 
There is no gravity. The earth sucks.

jmh530 <john.michael.hall gmail.com> writes:

On Thursday, 1 October 2020 at 05:23:51 UTC, Stefan Koch wrote:
 [snip]


 I can imagine a nice implementation of this, but since it 
 doesn't solve the performance problem, I am not interested.
 [snip]

It's a little unclear to me what you are talking about, but my 
understanding is that a big interest in stuff like Concepts is 
about improving error messages, rather than performance per se.