[cfe-dev] Feature Idea: Error Message Replacing

[Gordon Henriksen]

On 2009-06-06, at 09:32, AlisdairM(public) wrote:

>> This is a feature idea I just came up with. I have no concrete  
>> plans to
>> implement this, but I thought I'd post it to the list to see if  
>> others
>> like it as well, and to preserve it for future reference.
>>
>> I'm currently working on a Boost library, and in the compile errors
>> this
>> shows up:
>>
>> error: invalid use of incomplete type ‘struct
>> boost::property_tree::path_of<boost::any>’
>>
>> Because I've written this library, I know that this error really  
>> means,
>> "You haven't specialized the path_of struct for that template  
>> argument
>> you're trying to use, but this is a prerequisite." If I were a user  
>> of
>> the library, I'd have no clue.
>> I think there should be a way for the library author to communicate
>> this
>> knowledge to the user. I'm imagining something like this:
>>
>> --- File: boost/property_tree/ptree.hpp (the library's main  
>> include) --
>> -
>> #pragma clang error_catalog "boost/property_tree/property_tree.en.ec"
>>
>> // Users have to specialize this
>> template <typename Key> struct path_of;
>>
>>
>> --- File: boost/property_tree/property_tree.en.ec (pseudo-syntax) ---
>> match "invalid use of incomplete type 'struct
>> boost::property_tree::path_of<{T}>'"
>> replacement "you need to specialize 'boost::property_tree::path_of'  
>> for
>> '$T' in order to use it as a property tree key"
>>
>> Then, when I do
>>
>> boost::basic_ptree<boost::any, int> pt;
>>
>> I get the error
>>
>> error: you need to specialize 'boost::property_tree::path_of' for
>> 'boost::any' in order to use it as a property tree key
>>
>>
>> Error catalogs would be looked up either in the include path or some
>> separate lookup path; I would prefer the include path because it  
>> makes
>> using error catalogs "just work" for the library user. Error catalogs
>> are cumulative, i.e. you can have any number of error_catalog pragmas
>> in
>> a translation unit.
>>
>> Comments? With C++0x concepts, the need for this is obviously smaller
>> (my example is a result of a pseudo-concept emulation), but I think  
>> it
>> could still be useful.
>
> To an extent this is similar to an issue I would like to solve in C+ 
> +0x with another standard attribute (although I suspect the time for  
> even limited proposals is long past).  Essentially, there is a  
> problem that template struct path_of needs to be declared purely as  
> a means to define [partial] specializations - the primary template  
> itself is never designed to be instantiated.  There are templates  
> like this is in the standard library (std::function, for instance)  
> and it would be really nice to add an attribute that says 'you must  
> always provide a specialization for this template'.
>
> 	// Users have to specialize this
> 	template <typename Key> struct path_of [[not_defined]];
>
> Now your idea here goes further with linking the lack-of- 
> specialization to a specific library use for even better error  
> messages - I'm not sure how my simple attribute could cover that.

Don't concept maps cleanly provide the desired functionality for both  
of these cases? (Not that they're much help yet.)

— Gordon