> Date: Thu, 11 May 2023 00:46:23 -0400
> Cc: gcc@gcc.gnu.org
> From: Eli Schwartz via Gcc <gcc@gcc.gnu.org>
> 
> > And remember that `-traditional' DID exist for a certain amount of time.
> > Then it was removed.  So in addition to annoying a lot of people, what
> > guarantees that -Wno-implicit will not be removed in the future, after
> > the proposed changes are made?
> 
> 
> What guarantees of the future do you have for anything?
> 
> What guarantees do you have that a meteor won't hit Earth and wipe out
> all human life in a great catastrophe?
> 
> What guarantees do you have that GCC will still be run by the current
> maintainers?
> 
> What guarantees do you have that GCC will still be maintained at all?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std > c89, making -traditional the default,
> and becoming a historical recreation society?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std < c23, mandating that everyone upgrade
> to the very latest std that isn't even fully implemented today?
> 
> What guarantees do you have that reality exists as you think of it?
> Maybe you are a pink elephant and computers are a figment of your
> imagination.

Please be serious, and please don't mock your opponents.  This is a
serious discussion of a serious subject, not a Twitter post.

Back to the subject: the guarantees I would personally like to have is
that the current GCC development team sees backward compatibility as
an important goal, and will try not to break old programs without very
good technical reasons.  At least in Emacs development, that is the
consideration that is very high on our priority list when making
development decisions.  It would be nice if GCC (and any other GNU
project, for that matter) would do the same, because being able to
upgrade important tools and packages without fear is something users
value very much.  Take it from someone who uses GCC on various
platforms since version 1.40.

Reply via email to