RE: error message formatting

RE: error message formatting

[Kaz Kylheku]

On Friday, April 17, 1998 2:37 AM, Pieter Nagel [SMTP:pnagel@epiuse.co.za] 
wrote:
> On Fri, 17 Apr 1998, Anthony Shipman wrote:
>
> > I don't know what problems multiple-line error messages might cause for
> > other tools.
>
> They will break many IDE's which spawn the compiler in the
> background and capture it's error output.

The IDE's are broken. It is their responsibility to parse the compiler output
properly.

Vim, for instance, has few problems with multi-line errors. The only
annoyance is that each line is treated as an individual error, so
that it takes three :cn commands to step through a three line
error. Other than that, it's fine. If you bind a key to traverse the
errors, the aggravation is minimal.

Re: error message formatting

[Mike Stump]

> Date: Thu, 16 Apr 98 08:55:31 -0400
> From: David Cogen <cogen@ll.mit.edu>
> To: egcs@cygnus.com

> Yes (to both). Are these going to be difficult to implement?

I probably wouldn't find them difficult to implement.  The real
question is, would you find it difficult to implement?  :-) Everyone
usually (please, let me know if I am wrong) has plenty of work to keep
them busy.  You can either sit there and wait around for it, or you
can make it happen.  The rest of us would love it if you can find a
way to make it happen.

> What if there is more than one typedef for a template? Is there an obvious
> algorithm to choose the "correct" one? 

I think so, I'd just need to think about it some.  It might be as easy
as the shortest name wins.  :-)

Re: error message formatting

[Mike Stump]

> From: Anthony Shipman <als@tusc.com.au>
> Date: Wed, 15 Apr 1998 03:50:00 +1000 (EST)

> It would be nice if there was some readable formatting for error messages 
> instead of the following.  There are three very long lines here.

> fxg_glyph_mgr.cc:345: no matching function for call to `map<int,list<FXG_Glyph *,__default_alloc_template<false,0> > *,less<int>,__default_alloc_template<false,0> >::insert (__rb_tree_iterator<pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *>,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> *> &, list<FXG_Glyph *,__default_alloc_template<false,0> > *&)'

To be concrete, I think if we check to see if the type of a template
parameter is the default value for the parameter, it be not printed
if it would have been the last one printed.

Also, if there exists a typedef name for a type, then we use the
typedef name instead of the real name, if the real name is a template
of some kind.

Re: error message formatting

[Joe Buck]

> To be concrete, I think if we check to see if the type of a template
> parameter is the default value for the parameter, it be not printed
> if it would have been the last one printed.

Yes, this is what I proposed (presumably egcs list delays mean we didn't
see each other's postings until later).  This one would be fairly
straightforward and shouldn't cause problems.

> Also, if there exists a typedef name for a type, then we use the
> typedef name instead of the real name, if the real name is a template
> of some kind.

This one, on the other hand, may be trickier, because there are often
multiple typedefs referring to the same type (especially for maps and
sets: there is the map iterator as well as the rb_tree iterator).  It
might be tricky to decide which one to choose for display.

Re: error message formatting

[Per Bothner]

Somebody (Mike Stump?) wrote:
> Also, if there exists a typedef name for a type, then we use the
> typedef name instead of the real name, if the real name is a template
> of some kind.
Joe Buck <jbuck@synopsys.com> replied:
> This one, on the other hand, may be trickier, because there are often
> multiple typedefs referring to the same type (especially for maps and
> sets: there is the map iterator as well as the rb_tree iterator).  It
> might be tricky to decide which one to choose for display.

You use the typedef name used in the declaration.  That should be fairly
easy to get right, given the recent typdef support.  Mostly, be more
careful about when to use TYPE_MAIN_VARIANT and when not to.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: error message formatting

[Joe Buck]

I wrote:
> > This one, on the other hand, may be trickier, because there are often
> > multiple typedefs referring to the same type (especially for maps and
> > sets: there is the map iterator as well as the rb_tree iterator).  It
> > might be tricky to decide which one to choose for display.

Per writes:
> You use the typedef name used in the declaration.

This suffices when an error is reported in a function: report the function
the way it was declared.  But in the case of a mismatched argument, there
are two declarations: the type of the actual argument and the type the
function was expecting.  There can be even more declarations involved when
there is an overloading ambiguity.

But maybe it's OK to just show everything the way it was declared.  It
would be worth trying out.

Re: error message formatting

[David Cogen]

> To be concrete, I think if we check to see if the type of a template
> parameter is the default value for the parameter, it be not printed
> if it would have been the last one printed.
> 
> Also, if there exists a typedef name for a type, then we use the
> typedef name instead of the real name, if the real name is a template
> of some kind.

Yes (to both). Are these going to be difficult to implement?

I presume something similar will need to happen for gdb and other tools. I.e.,
there is no way that a change to gcc will make it happen "for free" in the
other tooks?

What if there is more than one typedef for a template? Is there an obvious
algorithm to choose the "correct" one? 

-- DavidC

error message formatting

[Anthony Shipman]

It would be nice if there was some readable formatting for error messages 
instead of the following.  There are three very long lines here.

fxg_glyph_mgr.cc:345: no matching function for call to `map<int,list<FXG_Glyph *,__default_alloc_template<false,0> > *,less<int>,__default_alloc_template<false,0> >::insert (__rb_tree_iterator<pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *>,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> *> &, list<FXG_Glyph *,__default_alloc_template<false,0> > *&)'
/usr/local/egcs/include/g++/stl_map.h:139: candidates are: map<int,list<FXG_Glyph *,__default_alloc_template<false,0> > *,less<int>,__default_alloc_template<false,0> >::insert(__rb_tree_iterator<pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *>,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> *>, const pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &)
/usr/local/egcs/include/g++/stl_map.h:138:                 map<int,list<FXG_Glyph *,__default_alloc_template<false,0> > *,less<int>,__default_alloc_template<false,0> >::insert(const pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &)

-- 
Anthony Shipman                 "You've got to be taught before it's too late,
TUSC Computer Systems Pty Ltd    Before you are six or seven or eight,
666 Doncaster Rd, Doncaster      To hate all the people your relatives hate,
Melbourne, Australia, 3108       You've got to be carefully taught."  R&H

Re: error message formatting

[David Cogen]

> It would be nice if there was some readable formatting for error messages 
> instead of the following.  There are three very long lines here.
> 
> fxg_glyph_mgr.cc:345: no matching function for call to `map<int,list<FXG_Glyph *,__default_alloc_template<false,0> > *,less<int>,__default_alloc_template<false,0> >::insert (__rb_tree_iterator<pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *>,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> *> &, list<FXG_Glyph *,__default_alloc_template<false,0> > *&)'
> /usr/local/egcs/include/g++/stl_map.h:139: candidates are: map<int,list<FXG_Glyph *,__default_alloc_template<false,0> > *,less<int>,__default_alloc_template<false,0> >::insert(__rb_tree_iterator<pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *>,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &,pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> *>, const pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &)
> /usr/local/egcs/include/g++/stl_map.h:138:                 map<int,list<FXG_Glyph *,__default_alloc_template<false,0> > *,less<int>,__default_alloc_template<false,0> >::insert(const pair<const int,list<FXG_Glyph *,__default_alloc_template<false,0> > *> &)
> 


Yes, This is OUTRAGEOUS!

If there is a typedef which takes fewer characters to express then the
original, it should use the typedef form.

If there is more than one typedef, then, if it is too hard to decide which to
use, then I don't care which it uses; anything as long as it is
comprehensible!!!!


This applies to the linker, and debugger as well. I don't want to see a mess
like the above example!!!!


(You don't want me to go back to writing in C, do you? :)


-- DavidC

Re: error message formatting

[Mark Schaefer]

	Anthony and David,

	Unfortunately, this is mainly due to the structure of the STL.  Because
it is so template based, you're going to get those long lines.  I think the SGI
compiler has some sort of line break macro that will allow it to divide a long
line response like that into something slightly more intelligible, but really,
the entire output could be extremely important to someone who had to debug
code. I had a problem due to a misplaced "const" that would have been
impossible to track down if the compiler hadn't put out long diagnostic errors
like that.

	Basically, if you want simplicity, STL is probably not the way to go.
 However, there are a whole lot of reasons why it pays to use STL instead of
coding and debugging your own template libraries.

Good Luck.

--
Mark Schaefer

Re: error message formatting

[David Cogen]

> 	Unfortunately, this is mainly due to the structure of the STL.  Because
> it is so template based, you're going to get those long lines.  I think the SGI

Yes, but, as I said, "This is OUTRAGEOUS".

Are you a compiler writer by the way?

No offense, but this sounds like an excuse by a compiler writer for not doing
something which is hard, not an explanation. I don't consider this an
acceptable answer.

I am stating what I, as the USER, wants to see. (The USER rules, or should!) I
know it's possible, because I can imagine algorithms which will do it. (E.g.,
a not-great algorithm might be: go over all the visible typedefs and
substitute when a typedef with fewer characters matches something with more
characters).

As templates get more common, something must be done about hiding their
names. I use them fairly regularly now. I have nested templates up to 3 levels
(e.g., map <string<char>, <vector <pair <int, float> > >)

if I have typefed that to my_map, that's what I want to see in my error
messages. 

-- DavidC

Re: error message formatting

[Joe Buck]

> > 	Unfortunately, this is mainly due to the structure of the STL.  Because
> > it is so template based, you're going to get those long lines.  I think the SGI
> 
> Yes, but, as I said, "This is OUTRAGEOUS".

The problem is partly fixable, and there have been several proposals.

> I am stating what I, as the USER, wants to see. (The USER rules, or should!)

The user does not rule egcs unless the user is paying someone to write the
code.  You don't rule because you aren't doing the work and you aren't
paying others to do the work.  Just the same, you'll probably see some
effort to deal with this problem, eventually.

> As templates get more common, something must be done about hiding their
> names. I use them fairly regularly now. I have nested templates up to 3 levels
> (e.g., map <string<char>, <vector <pair <int, float> > >)
> 
> if I have typefed that to my_map, that's what I want to see in my error
> messages. 

This sometimes works, but sometimes the only way to show the user the
problem is to expose the real definition (because the calling code
declared one typedef but the called code declared another typedef and
they are both the same).

Still, I think this is a promising area.  But we'll need volunteers to
code up some alternatives.

Re: error message formatting

[David Cogen]

> The user does not rule egcs unless the user is paying someone to write the
> code.  You don't rule because you aren't doing the work and you aren't
> paying others to do the work.  Just the same, you'll probably see some
> effort to deal with this problem, eventually.

Yes, of course you are right. I was being deliberately provocative because I am
tired of explanations using circular reasoning (Things are the way they are
because that's the way things are.) 

The USER rules, not the SOFTWARE. That is the distintion I was trying to make.

I said nothing about CYGNUS, or FSF, or anybody else. Sorry if anyone took it
that way.

-- DavidC

Re: error message formatting

[Per Bothner]

Recent changes by Ben Koznik and me have improved the situation.
(The relevant ChangeLog entries are dated April 9.)
Basically, g++ did not use to really "know" about typedefs
- that is it could not distinguish between two equivalent
types but with different typedef names.  This was changed
for C a couple of years ago, and was very recently changed in g++.

For a function:
JArray<jstring> foo (jint a, JArray<jint> b , jstring c)
{    return c+b; }
I now get:
/home/bothner/devo/libjava/prims.cc: In function `class JArray<java::lang::String *> foo(jint, class JArray<jint>, class java::lang::String *)':
/home/bothner/devo/libjava/prims.cc:943: no match for `java::lang::String *& + JArray<jint> &'

Notice the use of the jint typedef.  There is a still a problem in that
the typedef of jstring is being expanded; someone should look into
why that is still happening.

David Cogen <cogen@ll.mit.edu> writes:
> I am stating what I, as the USER, wants to see. (The USER rules, or should!)

Perhaps, but you, sir, are a LUSER.  Have you heard the expression
"don't look at gift horse in the mouth?"  Have you or your employer
*paid* anything for Gcc?  Have you contributed anything to Gcc?
If not, quit your unmannerly whining.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: error message formatting

[Anthony Shipman]

> 
> > 	Unfortunately, this is mainly due to the structure of the STL.  Because
> > it is so template based, you're going to get those long lines.  I think the SGI
> 
> Yes, but, as I said, "This is OUTRAGEOUS".
> 
> Are you a compiler writer by the way?
> 
> No offense, but this sounds like an excuse by a compiler writer for not doing
> something which is hard, not an explanation. I don't consider this an
> acceptable answer.
> 
> I am stating what I, as the USER, wants to see. (The USER rules, or should!) I
> know it's possible, because I can imagine algorithms which will do it. (E.g.,
> a not-great algorithm might be: go over all the visible typedefs and
> substitute when a typedef with fewer characters matches something with more
> characters).

When I sent the message what I had in mind was putting in line breaks
and indenting in the type descriptions so that it is easier to compare
the parts of the different type descriptions being written.

I don't know what problems multiple-line error messages might cause for
other tools.

Folding type descriptions down to typedefs would be something extra to
increase understandibility.  Perhaps it would be optional since there
may be cases where you want to see the entire expansion.

-- 
Anthony Shipman                 "You've got to be taught before it's too late,
TUSC Computer Systems Pty Ltd    Before you are six or seven or eight,
666 Doncaster Rd, Doncaster      To hate all the people your relatives hate,
Melbourne, Australia, 3108       You've got to be carefully taught."  R&H

Re: error message formatting

[Pieter Nagel]

On Fri, 17 Apr 1998, Anthony Shipman wrote:

> I don't know what problems multiple-line error messages might cause for
> other tools.

They will break many IDE's which spawn the compiler in the
background and capture it's error output.

-- 
     ,_
     /_)              /| /
    /   i e t e r    / |/ a g e l

Re: error message formatting

[David Cogen]

> When I sent the message what I had in mind was putting in line breaks
> and indenting in the type descriptions so that it is easier to compare
> the parts of the different type descriptions being written.

What you want is a "pretty printer" for compiler diagostic output. I already
use one such pretty printer; it's called g++filt; that's for a different
purpose: name unmangling however. I.e., my make command is something like:

    make MAKETARGET |& g++filt

This could be cascaded:

    make MAKETARGET |& g++filt |& g++pprint

where g++pprint is a filter which pretty prints the diagostic output. It could
be based on perl, perhaps, matching and replacing based on regular
expressions. 

-- DavidC

Re: error message formatting

[Joe Buck]

[ long error messages ]

> 	Unfortunately, this is mainly due to the structure of the STL.  Because
> it is so template based, you're going to get those long lines.

Well, it's possible to shorten the lines in several ways, or to break them
("pretty-print"), or to try to use typedefs, etc.

> 	Basically, if you want simplicity, STL is probably not the way to go.

I disagree: use of the STL can have a big payoff in terms of simplicity
(unless you get carried away and try to do complex functional programming
with function objects and adaptors -- such programs are hard to read and
maintain, it seems to me).

It is up to the egcs team as compiler implementers to figure out ways of
making decent error messages for STL code.

STL also puts stress on the name mangler; one approach is to claim that
it is an inevitable consequence of the STL, but there are more productive
approaches, such as the new -fsquangle in the snapshots.

Re: error message formatting

[Craig Burley]

>(You don't want me to go back to writing in C, do you? :)

Uh...yes?

(Nothing personal; I'm not a big fan of C++ as a programming
language.  ;-)

        tq vm, (burley)

Re: error message formatting

[Joe Buck]

> It would be nice if there was some readable formatting for error messages 
> instead of the following.  There are three very long lines here.

[ Huge errors deleted ]

One possibility would be to suppress template arguments when they match
the default.  We then have

> fxg_glyph_mgr.cc:345: no matching function for call to `map<int,list<FXG_Glyph *> *>::insert (__rb_tree_iterator<pair<const int,list<FXG_Glyph *> *>,pair<const int,list<FXG_Glyph *> *> &,pair<const int,list<FXG_Glyph *> *> *> &, list<FXG_Glyph *> *&)'
> /usr/local/egcs/include/g++/stl_map.h:139: candidates are: map<int,list<FXG_Glyph *> *>::insert(__rb_tree_iterator<pair<const int,list<FXG_Glyph *> *>,pair<const int,list<FXG_Glyph *> *> &,pair<const int,list<FXG_Glyph *> *> *>, const pair<const int,list<FXG_Glyph *> *> &)
> /usr/local/egcs/include/g++/stl_map.h:138:                 map<int,list<FXG_Glyph *> *>::insert(const pair<const int,list<FXG_Glyph *> *> &)> 

which is much more readable.  To do better we'd have to put typedefs into
symbols, which makes me nervous, though we could have a mechanism to do
it only for the standard classes.

Re: error message formatting

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    >> It would be nice if there was some readable formatting for
    >> error messages instead of the following.  There are three very
    >> long lines here.

    Joe> [ Huge errors deleted ]

    Joe> One possibility would be to suppress template arguments when
    Joe> they match the default.  We then have

We have to be careful that we don't introduce ambiguity in the
process.  It may be possible to do so by dropping defaulted arguments,
e.g.:

  template <class T, class U = T**>
  void f();

  template <class T*, class U = T*>
  void f();

Now, f<int*> is ambiguous, but f<int*, int**> is not.  

-- 
Mark Mitchell <mmitchell@usa.net>
http://home.earthlink.net/~mbmitchell
Consulting Services Available

Re: error message formatting

[Alexandre Oliva]

Mark Mitchell writes:

> We have to be careful that we don't introduce ambiguity in the
> process.  It may be possible to do so by dropping defaulted arguments,

>   template <class T, class U = T**>
>   void f();

>   template <class T*, class U = T*>
>   void f();

`classs T*' is not a valid template argument declaration.

However, the raised issue is a valid one.  Suppose one declares:

template <typename T, int i = 1> void f();
template <typename T, char e = '\0'> void f();

Then he calls f<int>().  The compiler must report an ambiguity but, if 
we remove trailing default arguments, the error message would look
like:

?:?:Template function call is ambiguous.  Available specializations are:
?:?:	f<int>()
?:?:	f<int>()

This would seem rather confusing, although line numbers might help.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: error message formatting

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

    Alexandre> Mark Mitchell writes:

    >> We have to be careful that we don't introduce ambiguity in the
    >> process.  It may be possible to do so by dropping defaulted
    >> arguments,

    >> template <class T, class U = T**> void f();

    >> template <class T*, class U = T*> void f();

    Alexandre> `classs T*' is not a valid template argument
    Alexandre> declaration.

Thank you for the improved example.  I *knew* when I wrote what I did
that I didn't have it right, but I didn't have time to think about it
carefully.  What an embarrassing mistake!

    Alexandre> However, the raised issue is a valid one.  Suppose one
    Alexandre> declares:

    Alexandre> template <typename T, int i = 1> void f(); template
    Alexandre> <typename T, char e = '\0'> void f();

    Alexandre> Then he calls f<int>().  The compiler must report an
    Alexandre> ambiguity but, if we remove trailing default arguments,
    Alexandre> the error message would look like:

    Alexandre> ?:?:Template function call is ambiguous.  Available
    Alexandre> specializations are: ?:?: f<int>() ?:?: f<int>()

    Alexandre> This would seem rather confusing, although line numbers
    Alexandre> might help.

    Alexandre> -- Alexandre Oliva mailto:oliva@dcc.unicamp.br
    Alexandre> mailto:aoliva@acm.org http://www.dcc.unicamp.br/~oliva
    Alexandre> Universidade Estadual de Campinas, SP, Brasil

-- 
Mark Mitchell <mmitchell@usa.net>
http://home.earthlink.net/~mbmitchell
Consulting Services Available

Re: error message formatting

[David Cogen]

> which is much more readable.  To do better we'd have to put typedefs into
> symbols, which makes me nervous, though we could have a mechanism to do
> it only for the standard classes.
 

"Only for the standard classes"?

Not good enough.



-- DavidC

Re: error message formatting

[David Cogen]

> "Only for the standard classes"?
> 
> Not good enough.
 
This (and my previous) may come across rather more nasty than I intended. It
was not meant as a criticism of the work that Cygnus or FSF is doing, or as an
expectation of entitlement. It was about users vs software only, and making a
point that we shouldn't have to adjust our expectations to the software;
rather the other way around. I am sorry if anyone was annoyed by it and will
watch myself from now on.


So anyway (ignoring the possible difficulty of implementation for now), in
terms of user benefit only, why would implementing typedef aliases in error
messages for "standard classes" only be a huge benefit? Standard classes are a
starting point only in a big system, and the number of user classes in a big
system will likely outnumber the standard ones.

Yes, I do appreciate the difficulties. I don't even see a good method to
select among multiple typedefs for the same template type (unless one comes
from a standard <...> header file and one from a "..." file; in this case use
the "..." one). Perhaps in this case it is appropriate to simply choose one,
arbitrarily. 

With a c++ extension: newtypedef, it would be clear what to do. newtypedef,
unlike typedef, would define a new type, not an alias to an existing
type. Of course this is not standard c++, but it would solve the problem.


DavidC

Re: error message formatting

[Lassi A. Tuura]

Joe Buck wrote:
|> One possibility would be to suppress template arguments when they match
|> the default.  We then have
|> 
|> > fxg_glyph_mgr.cc:345: no matching function for call to `map<int,list<FXG_Glyph *> *>::insert (__rb_tree_iterator<pair<const int,list<FXG_Glyph *> *>,pair<const int,list<FXG_Glyph *> *> &,pair<const int,list<FXG_Glyph *> *> *> &, list<FXG_Glyph *> *&)'
|> > /usr/local/egcs/include/g++/stl_map.h:139: candidates are: map<int,list<FXG_Glyph *> *>::insert(__rb_tree_iterator<pair<const int,list<FXG_Glyph *> *>,pair<const int,list<FXG_Glyph *> *> &,pair<const int,list<FXG_Glyph *> *> *>, const pair<const int,list<FXG_Glyph *> *> &)
|> > /usr/local/egcs/include/g++/stl_map.h:138:                 map<int,list<FXG_Glyph *> *>::insert(const pair<const int,list<FXG_Glyph *> *> &)> 

How about something like this?

 ...: no matching function for call to map<T1,T2>::insert (__rb_tree_iterator<T3,T3 &,T3 *> &,T2 &)'
 ...: candidates are: map<T1,T2>::insert (__rb_tree_iterator<T3,T3 &,T3 *>, const T3 &)
 ...:                 map<T1,T2>::insert (const T3 &)
 ...:   (where T1=int, T2=list<FCG_Glyph *> *, T3=pair<const T1,T2>)


The generation of such messages should be relatively straightforward: 
during the message generation, keep track of all types seen template
arguments and substitute as many as you can, but not creating new types
for cv-qualified and pointer-decorated versions.  The results are, IMHO,
as readable as they can get.  One could still fiddle with showing the
actual declared function parameter types (map<T1,T2>::iterator instead
of __rb_tree_iterator in this case) for improved clarity (is that
information still available?).

With this scheme templates with lots of arguments would still be at
least somewhat readable.  Hence, there would not be such a need to
supporess default arguments.  For instance, map would really be
`map<T1,T2,T3,T4>', where at the end of error messages `T3' would be
shown as `less<T1>' and `T4' as `allocator<T2>' (or whatever user
substituted).

Cheers,
//lat
--
Every old idea will be proposed again with a different name and a
different presentation, regardless of whether it works. --RFC1925