December 14, 2010
bearophile wrote:
> Andrei:
> 
>> D's constrained templates were introduced on 17 June 2008 and they've been
>> a smashing hit. Virtually all of Phobos uses them, and I'm sure a lot of
>> generic client code. They take half a minute to explain and solve a
>> difficult problem in a very simple manner.<
> 
> A template with two constrains makes it less handy to add error messages that
> explain why the instantiation has failed:

Adding such error messages misses the point of constraints. The idea is that template overloading is based on constraints. Given 3 templates with 3 constraints, overload resolution picks the one with constraints that pass. Giving error messages for the others is wrong.

If you want it to produce error messages if the instantiation is wrong, the correct way is to use static asserts within the template body. No additional features serve any purpose.
December 14, 2010
Walter:

> Adding such error messages misses the point of constraints. The idea is that template overloading is based on constraints. Given 3 templates with 3 constraints, overload resolution picks the one with constraints that pass. Giving error messages for the others is wrong.

You are right, I miss things all the time :-) Thank you for your patience.


> If you want it to produce error messages if the instantiation is wrong, the correct way is to use static asserts within the template body. No additional features serve any purpose.

If the purpose is to produce error messages if the instantiation is wrong, then using a "static precondition" instead of normal free static asserts may give a bit better error messages (errors at the instantiation point instead of inside the template). But I guess this is just a limit of the compiler, not a problem of the language...

Bye,
bearophile
December 14, 2010
Walter Bright wrote:
> bearophile wrote:
>> Andrei:
>>
>>> D's constrained templates were introduced on 17 June 2008 and they've been
>>> a smashing hit. Virtually all of Phobos uses them, and I'm sure a lot of
>>> generic client code. They take half a minute to explain and solve a
>>> difficult problem in a very simple manner.<
>>
>> A template with two constrains makes it less handy to add error messages that
>> explain why the instantiation has failed:
> 
> Adding such error messages misses the point of constraints. The idea is that template overloading is based on constraints. Given 3 templates with 3 constraints, overload resolution picks the one with constraints that pass. Giving error messages for the others is wrong.
> 
> If you want it to produce error messages if the instantiation is wrong, the correct way is to use static asserts within the template body. No additional features serve any purpose.

Actually I think there's considerable potential for better error messages.

Currently, if constraints fail for all templates, the error message prints the full constraint for the first template, which is not very helpful.
A huge improvement would be to distinguish "no templates match at all", (eg the number of parameters is different)
from "there are templates which would match, except that the template constraints fail".






December 14, 2010
On Tuesday 14 December 2010 00:23:58 Walter Bright wrote:
> bearophile wrote:
> > Andrei:
> >> D's constrained templates were introduced on 17 June 2008 and they've been a smashing hit. Virtually all of Phobos uses them, and I'm sure a lot of generic client code. They take half a minute to explain and solve a difficult problem in a very simple manner.<
> > 
> > A template with two constrains makes it less handy to add error messages that
> 
> > explain why the instantiation has failed:
> Adding such error messages misses the point of constraints. The idea is that template overloading is based on constraints. Given 3 templates with 3 constraints, overload resolution picks the one with constraints that pass. Giving error messages for the others is wrong.
> 
> If you want it to produce error messages if the instantiation is wrong, the correct way is to use static asserts within the template body. No additional features serve any purpose.

It could definitely serve a purpose if _all_ of the possible template specializations fail. Presumably, you intend _one_ of them to work. But that _does_ mean that you get error messages for a number of different template specializations, and you have to sort through them. It _can_ take a fair bit of effort to figure out why a particular template constraint is failing, and it would definitely be nice if there were more information on _why_ a template constraint fails.

However, I do agree that doing so could get rather complicated, and that ultimately, it probably isn't worth it. I fully expect, however, that many people in the future will complain that they can't get better error messages which indicate why a particular template constraint failed.

- Jonathan M Davis
December 14, 2010
On Tuesday 14 December 2010 00:45:02 Don wrote:
> Walter Bright wrote:
> > bearophile wrote:
> >> Andrei:
> >>> D's constrained templates were introduced on 17 June 2008 and they've
> >>> been
> >>> a smashing hit. Virtually all of Phobos uses them, and I'm sure a lot
> >>> of generic client code. They take half a minute to explain and solve a
> >>> difficult problem in a very simple manner.<
> >> 
> >> A template with two constrains makes it less handy to add error messages that
> > 
> >> explain why the instantiation has failed:
> > Adding such error messages misses the point of constraints. The idea is that template overloading is based on constraints. Given 3 templates with 3 constraints, overload resolution picks the one with constraints that pass. Giving error messages for the others is wrong.
> > 
> > If you want it to produce error messages if the instantiation is wrong, the correct way is to use static asserts within the template body. No additional features serve any purpose.
> 
> Actually I think there's considerable potential for better error messages.
> 
> Currently, if constraints fail for all templates, the error message
> prints the full constraint for the first template, which is not very
> helpful.
> A huge improvement would be to distinguish "no templates match at all",
> (eg the number of parameters is different)
> from "there are templates which would match, except that the template
> constraints fail".

Simply indicating that some of the templates' signatures match (or that none do) but that their constraints fail would be useful. Right now, you don't even know whether its the signature that doesn't match or whether it's the constraint that fails.

- Jonathan M Davis
December 14, 2010
On 12/14/10 2:23 AM, Walter Bright wrote:
> bearophile wrote:
>> Andrei:
>>
>>> D's constrained templates were introduced on 17 June 2008 and they've
>>> been
>>> a smashing hit. Virtually all of Phobos uses them, and I'm sure a lot of
>>> generic client code. They take half a minute to explain and solve a
>>> difficult problem in a very simple manner.<
>>
>> A template with two constrains makes it less handy to add error
>> messages that
>> explain why the instantiation has failed:
>
> Adding such error messages misses the point of constraints. The idea is
> that template overloading is based on constraints. Given 3 templates
> with 3 constraints, overload resolution picks the one with constraints
> that pass. Giving error messages for the others is wrong.
>
> If you want it to produce error messages if the instantiation is wrong,
> the correct way is to use static asserts within the template body. No
> additional features serve any purpose.

Yah, I was planning on writing the same response.

Andrei
December 14, 2010
On Tue, 14 Dec 2010 01:43:11 -0600
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> > I'm also a bit more of a
> > fan of C++0x concepts than those contraints shown in the slides. I
> > haven't really thought how it all would work out, but if the atmosphere
> > was more ambitious to this direction, I could participate more. But it
> > seems my vision conflicts badly with what D2 has become.
> 
> In all honesty, it is difficult to infer your vision from the trail of your posts.
> 
> As of C++ concepts, let me mention a few facts fresh from the source (I literally collected them an hour ago). C++ concepts are dead, buried, and decomposing. Nobody is working on them and there is exactly one guy in the world still talking about them. For a variety of theoretical and practical purposes, they will never make it in C++.
> 
> D's constrained templates were introduced on 17 June 2008 and they've been a smashing hit. Virtually all of Phobos uses them, and I'm sure a lot of generic client code. They take half a minute to explain and solve a difficult problem in a very simple manner.
> 
> I'm not saying you can't convince that C++-style concepts would be superior. I'm saying you'll need to bring some solid evidence to the table. If you don't, please don't claim you're being ostracized :o).


About "concept" + "programming", you may have a look at XL http://xlr.sourceforge.net/concept/toplevel.html (an extensible PL, or a set of PLs, built to support "concept programming") (more info at http://xlr.sourceforge.net/concept/top.html). This language also has a very clear (semantics) & nice (syntax) template/generics system... with constraints (done right, imo). (Example at http://xlr.sourceforge.net/examples/maximum.html)


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

December 14, 2010
On 12/14/10 2:45 AM, Don wrote:
> Walter Bright wrote:
>> bearophile wrote:
>>> Andrei:
>>>
>>>> D's constrained templates were introduced on 17 June 2008 and
>>>> they've been
>>>> a smashing hit. Virtually all of Phobos uses them, and I'm sure a
>>>> lot of
>>>> generic client code. They take half a minute to explain and solve a
>>>> difficult problem in a very simple manner.<
>>>
>>> A template with two constrains makes it less handy to add error
>>> messages that
>>> explain why the instantiation has failed:
>>
>> Adding such error messages misses the point of constraints. The idea
>> is that template overloading is based on constraints. Given 3
>> templates with 3 constraints, overload resolution picks the one with
>> constraints that pass. Giving error messages for the others is wrong.
>>
>> If you want it to produce error messages if the instantiation is
>> wrong, the correct way is to use static asserts within the template
>> body. No additional features serve any purpose.
>
> Actually I think there's considerable potential for better error messages.
>
> Currently, if constraints fail for all templates, the error message
> prints the full constraint for the first template, which is not very
> helpful.
> A huge improvement would be to distinguish "no templates match at all",
> (eg the number of parameters is different)
> from "there are templates which would match, except that the template
> constraints fail".

Yes, printing the first constraint is quite random. This should be listed as a bug.

Andrei
December 14, 2010
On Tue, 14 Dec 2010 00:49:10 -0800
Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> It could definitely serve a purpose if _all_ of the possible template specializations fail. Presumably, you intend _one_ of them to work. But that _does_ mean that you get error messages for a number of different template specializations, and you have to sort through them. It _can_ take a fair bit of effort to figure out why a particular template constraint is failing, and it would definitely be nice if there were more information on _why_ a template constraint fails.

The case is analog to producing a sensible parsing error message in case of a choice:
	P	: P1 | P2 | P3
The only solutions are to ignore the issue or to provide error messages for every Pi. This gives for instance:

unittest{
    auto a = character('a');
    auto b = character('b');
    auto c = character('c');
    auto ch = choice(a, b, c)("ch");
    ch.match("d");
}
==>
******************************************************************
Match Failure: cannot match expected pattern.
   pattern : ch=('a'|'b'|'c')
   index   : 0
   found   : d
Failure reasons for sub-patterns:
******************************************************************
    ******************************************************************
    Match Failure: cannot match expected pattern.
       pattern : 'a'
       index   : 0
       found   : d
    ******************************************************************
    ******************************************************************
    Match Failure: cannot match expected pattern.
       pattern : 'b'
       index   : 0
       found   : d
    ******************************************************************
    ******************************************************************
    Match Failure: cannot match expected pattern.
       pattern : 'c'
       index   : 0
       found   : d
    ******************************************************************

(Actually, the parsing lib does not yet indent sub-pattern error messages -- I cheated.)
I guess a similar scheme can be used for template error messages (when _all_ versions fail).


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

December 14, 2010
Le 14/12/10 09:56, Andrei Alexandrescu a écrit :
> On 12/14/10 2:23 AM, Walter Bright wrote:
>> bearophile wrote:
>>> Andrei:
>>>
>>>> D's constrained templates were introduced on 17 June 2008 and they've
>>>> been
>>>> a smashing hit. Virtually all of Phobos uses them, and I'm sure a lot of
>>>> generic client code. They take half a minute to explain and solve a
>>>> difficult problem in a very simple manner.<
>>>
>>> A template with two constrains makes it less handy to add error
>>> messages that
>>> explain why the instantiation has failed:
>>
>> Adding such error messages misses the point of constraints. The idea is
>> that template overloading is based on constraints. Given 3 templates
>> with 3 constraints, overload resolution picks the one with constraints
>> that pass. Giving error messages for the others is wrong.
>>
>> If you want it to produce error messages if the instantiation is wrong,
>> the correct way is to use static asserts within the template body. No
>> additional features serve any purpose.
>
> Yah, I was planning on writing the same response.
>
> Andrei

I have a question about this and some pieces of code in the standard library, notably std.algorithm: some of the templated functions use template constraints even when no template overloading is taking place. Wouldn't some static asserts help print more accurate messages when these functions are misused?

Nicolas