[PATCH] D23875: Ease dealing with tagged enum ErrorDescription with some macros.

[Filipe Cabecinhas via llvm-commits]

I'll keep it as is, but having a hypothetical case is very different from
"we're in the middle of doing this, that's the end goal, I'd like so save a
bunch of work, even if right now the savings aren't that big".
After all, it wouldn't make much sense to stop after converting a few of
these functions.

Thank you,

 Filipe


On Thursday, 8 September 2016, Vitaly Buka <vitalybuka at google.com> wrote:

> Then let's keep it on hold. It does not improve code as is. We should
> avoid adding real complexity to simplify hypothetical use-cases.
>
> On Thu, Sep 8, 2016 at 11:34 AM Filipe Cabecinhas <
> filcab+llvm.phabricator at gmail.com
> <javascript:_e(%7B%7D,'cvml','filcab%2Bllvm.phabricator at gmail.com');>>
> wrote:
>
>> It will save much more after the other errors are reified. Putting it in
>> now avoids writing all that mechanical code which we know we will delete.
>>
>> All the Report* functions (one per error) will have a structure to
>> describe that error. Now there are 4 of those. Later they will be around 12
>> (don't have the code handy right now).
>>
>> Thank you,
>>
>>  Filipe
>>
>>
>> On Thursday, 8 September 2016, Vitaly Buka <vitalybuka at google.com
>> <javascript:_e(%7B%7D,'cvml','vitalybuka at google.com');>> wrote:
>>
>>> vitalybuka added a comment.
>>>
>>> It saves 9 line of code, but makes it less readable.
>>> I strongly prefer existing code.
>>>
>>>
>>> https://reviews.llvm.org/D23875
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160908/0904141d/attachment.html>