Re: [boost] [metaparse] Review period starts May 25th and ends June 7th - ongoing

Subject: Re: [boost] [metaparse] Review period starts May 25th and ends June 7th - ongoing
From: Roland Bock (rbock_at_[hidden])
Date: 2015-06-09 01:03:32

Hi Abel,

On 2015-06-08 21:26, Abel Sinkovics wrote:
> On 2015-06-08 08:02, Roland Bock wrote:
>> I believe that there is still room for improvement regarding the error
>> messages in case of a parse error. I described the idea of a portable
>> static_assert in my talk at MeetingC++ in Berlin last year: For each
>> potential problem (i.e. for each of the BOOST_STATIC_ASSERTs that you
>> now have), define a struct with a static method that fires a
>> static_assert when called. In case of an error, transport this class
>> from the problem-location to the TMP-call-site and call that static
>> method. This way you can produce a very targeted message with a very
>> short TMP call stack.
>>
>> Haven't looked deep enough to say if this pattern is actually
>> applicable.
> [...]
> What might be done based on your portable static assertion approach is
> adding a static method to these error classes representing the
> compilation errors to "static assert themselves" with better error
> messages. My concern about this is loosing the details of the error
> (position in the parsed text, the range boundaries and the index in
> case of an out of range error, etc). I'll check if "static assert
> yourself" can be done without loosing that information.
I had similar concerns at the beginning. It turned out (at least in my
case) that the "lost information"

  * might be relevant for the developer of the library
  * was just hiding the relevant things from the user

Whether the same is true for Metaparse, I don't know.

>
>> I tried a few of the examples in https://github.com/sabel83/metaparse
>> using clang-3.5.1 -std=c++11.
>>
>> The only problem I encountered was in example/parsing_error. It did not
>> produce an error at first. I had to remove a comment. It turned out
>> there was a spelling error in the comment leading to a compile error
>> that was not intended, I guess. After fixing that, I think I saw the
>> intended error message which I found a bit hard to grok.
> I'll fix the typo. The idea there is that the commented code fails to
> compile, however commenting that out and using debug_parsing_error can
> display the above mentioned (very user-friendly) text explanation of
> the error. I'll add some further explanation on this to the README of
> the example.
Thanks for the explanation. That is a neat feature :-)

Best,

Roland