Re: possible red flag for new C++ parser

[Tom Lord <lord at emf dot net>]

       Given that 3.4 will not be out until late this year at the
       earliest, application writers will have one year to fix their
       code. And Mark et al do and will certainly make sure that most
       regressions found by then will be fixed until the release. And
       even more time until vendors will use 3.4 as the base for their
       releases.

       So no reason to suggest that the new parser will be a serious
       threat to the gcc project, or that the end of the world is
       close.

I hope that the overall subjunctive voice of my red flag is not too
subtle for the list.

Now when you say that developers "will have one year to fix their
code"...

Doesn't that presume that they, or someone on their behalf, is trying
out the unreleased parser on their code?   I don't have any definitive
answers or analysis about that, but the implicit "forcing function"
here really raises my eyebrows.


     It will be a threat to projects that don't care to bring their
     sources into accordance with language standards, but that's not
     something that we should be concerned about.

Why not?  What if such projects overlap with either or both the goals
of the GNU project or the product lines of the vendors?

To be sure -- it's a purely hypothetical concern until the size of the
problem actually measured.


     Also not a concern for the C++ packages everybody cares about
     (e.g. KDE), they'll certainly make sure their code is ok.

It _is_ a concern, nonetheless.  If we care about projects (e.g. KDE)
then we must care about the development costs we impose upon those
projects and, if the costs are necessarilly non-trivial, seek economic
means to minimize them.   If we were collectively a closed,
proprietary shop -- this would be a no brainer.

-t