Re: [boost] Standalone boost::ignore_unused_variable_warning()

Subject: Re: [boost] Standalone boost::ignore_unused_variable_warning()
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-05-19 11:24:19

2014-05-19 16:48 GMT+02:00 Andrey Semashev <andrey.semashev_at_[hidden]>:

> On Monday 19 May 2014 16:40:05 Adam Wulkiewicz wrote:
> > Hi,
> >
> > 2014-05-19 15:00 GMT+02:00 Peter Dimov <lists_at_[hidden]>:
> > > Adam Wulkiewicz wrote:
> > >> I requested a pull for unused_variable:
> > >> https://github.com/boostorg/utility/pull/8
> > >
> > > It should be just ignore_unused_variable, IMO. It doesn't ignore the
> > > warning, it suppresses or avoids it.
> >
> > To be semantically correct it could be named use_variable() or
> > use_variables(). Or just unused_variable() / unused_variables() meaning
> > "hey! those are unused variables!". And if the name was changed we might
> as
> > well consider putting it in the different namespace, e.g.
> > boost::utility::unused_variables().
> >
> > The currently used name is for backward compatibility. We can change it
> or
> > provide both and deprecate the old one.
> > Or just leave currently defined one in the ConceptCheck but in this case
> > this pull request has less sense than it could.
>
> I'm in favor of renaming. ignore_unused_variable or
> suppress_unused_variable_warning looks more appealing to me. use_variable
> means "do something with it" to me, which is not the intention of the
> component.
>
> Is this a documented feature of ConceptCheck? If not, backward
> compatibility
> is not an issue.
>

It's only mentioned here:
http://www.boost.org/doc/libs/1_55_0/libs/concept_check/implementation.htm
but it's used probably in every library which is using ConceptCheck.
Plus a few libraries defines it with the same name in their details.

So to allow the maintainers to remove their definition and not force them
to modify every file where it's used we should probably leave this
1-parameter version of boost::ignore_unused_variable_warning() and provide
more flexible replacements.

Regards,
Adam