This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__
- From: Joe Buck <jbuck at synopsys dot COM>
- To: mark at codesourcery dot com (Mark Mitchell)
- Cc: aj at suse dot de (Andreas Jaeger),neil at daikokuya dot demon dot co dot uk (Neil Booth),jsm28 at cam dot ac dot uk (Joseph S. Myers), gcc at gcc dot gnu dot org (gcc at gcc dot gnu dot org)
- Date: Tue, 11 Dec 2001 12:19:15 -0800 (PST)
- Subject: Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__
Mark writes:
> I think this is a difficult question. It's clear that the change
> Neil and Joseph are in favor of is an improvement from the point of
> view of language semantics. Making __FUNCTION__ behave like __func__
> is a good thing; the __func__ semantics are better. The GCC
> simplifications resulting are real and significant.
>
> Neil has proposed deprecating this in GCC 3.0.3 so that we can
> then not support it in GCC 3.1. Deprecating something in a
> dot-release is a little dodgy.
>
> Andreas suggested deprecating it in 3.1 and removing it 3.2, which
> is definitely less dodgy -- but also means we have to remember this
> debate for several more months -- at least until after we branch for
> 3.1 in February.
You could go ahead and do the deprecation in the trunk now, since it will
become 3.1. The last time we fought about something like this in the SC
(-traditional), the consensus seemed to be be against deprecating
something in a bug-fix release (e.g. 3.0.3) that wasn't deprecated before.
This means that it's harder and takes longer to make features go away,
but that's a *good* thing. We should be slow and careful either in
adding extensions or in taking them away.
> I agree with Andreas, i.e, deprecate this in 3.1, and remove it 3.2.
> Therefore, I would pre-approve the patch for the moment that the 3.1
> branch is announce, and pre-approve a deprecation patch for both
> 3.0.3 and 3.1.
OK with me. I think there's no problem with your approving this unless
some SC member objects.