From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Cogen <cogen@ll.mit.edu>
To: cogen@ll.mit.edu
Cc: egcs@cygnus.com
Subject: Re: error message formatting
Date: Thu, 16 Apr 1998 13:53:00 -0000
Message-id: <9804161252.AA13757@LL.MIT.EDU>
References: <9804160857.AA21284@LL.MIT.EDU>
X-SW-Source: 1998-04/msg00639.html

> "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