This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Make parser revert digraph "<:"
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> "Zack Weinberg" <zack@codesourcery.com> writes:
>
> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> |
> | > | While this diagnostic is technically more accurate, I think it's both
> | > | more confusing and poorer English. How's this?
> | > |
> | > | error: '<::' cannot begin a template-argument list
> | >
> | > The confusing thing about this suggestion is that the beginning of the
> | > template-argument list is not '<::'.
> |
> | But it is '<::', in the most important place: in the source file.
>
> Yes, but it is not the beginning of the template-argument list!
> The beginning is the single character '<'.
Yes, but the maximally helpful diagnostic doesn't mention this. The
problem was that the compiler tokenized the three-character sequence
<:: a different way than the programmer intended; therefore the
diagnostic should make specific reference to that three-character
sequence and indicate that it was tokenized differently from the
intent.
Therefore I think that "'<::' cannot begin a template-argument list"
(with additional explanation in note:s) is clear and factually
accurate, while remaining appropriately brief.
> | #pragma STDCXX (DIGRAPHS|TRIGRAPHS) (ON|OFF)
> |
> | ? This would be trivial to implement under the #pragma GCC namespace
> | as a demonstration.
>
> I'm afraid anything that starts with pragma is not a first step.
Why? The alternative is to contort the grammar in order to make
digraphs be parsed as "intended", when what is really wanted is for
there not to be digraphs at all.
> This kind of thing can be handled without pragma/dogma intervening.
> I've already seen a patch for the ">>" thingy.
The >> thingy, yeah, that does need to be handled by contorting the
grammar, because there's no practical way to get rid of the >> token
at this stage; but the <: token *can* be dispensed with, under
programmer control.
> | > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1512.html
> | >
> | > for things like
> | >
> | > vector<list<int>> vl;
> |
> | What is GJ?
>
> I don't understand what you mean by "GJ".
quoting the website you referenced:
ES018. >>
Allow >> to terminate two specializations; e.g.
vector<list<int>> vli;
Not being able to do this surprises and annoys novices, leads to
harder to read code, and occationally catches even experts. It has
also become the target of a popular jibe from GJ proponents.
That GJ.
zw