Re: [boost] Removing old config macro and increasing compiler requirements.

Subject: Re: [boost] Removing old config macro and increasing compiler requirements.
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-08-05 10:49:19

On 08/05/2013 04:30 PM, Dave Abrahams wrote:
> on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
>
>> On 08/04/2013 12:57 PM, Daniel James wrote:
>>>> That obviously does not help with forward momentum
>>>> in efforts like this, and I expect the boost community has a solution to
>>>> that problem.
>>> Do you have any evidence for that? No one opposed your original change.
>> I don't have specific information on what minimum compiler version would
>> enable which interdependency culling, no. I only have the hard
>> information that increasing the requirement allows cutting the
>> config->core dependency, and the any->static_assert dependency.
>>
>> It is not unreasonable to think that the pattern ends there, 
> Did you mean the opposite?  I presume you are arguing that the pattern
> probably continues. 

Yes.

>  (People who make non-trivial arguments shouldn't
> throw double-negatives?)

Very good :).

>> so I don't think further evidence is necessary. 
> "It is not unreasonable to think" doesn't demonstrate anything, so
> it's also (ahem) not unreasonable to want to see more evidence. :-)

I've looked at boost::any in an updated boost repo (mine was an obsolete
boost-zero repo which has not been updated in a long time). The uses of
other features of type_traits has grown there, so more modularization
work would be needed.

Actually I thought that upgrading the compiler requirement would be such
a no-brainer as to require no further evidence of its usefulness than I
already presented. If that's not the case, then *shrug*.

>> I think what is necessary is for the boost community to pick increased
>> compiler requirements for the purpose of proceeding with
>> modularization, 
> Why is that necessary?  Aren't individual library authors fully capable
> of making the decision to drop support for an old compiler because it's
> pulling in a dependency they don't really want?

If that's how boost works, then you're telling me :).

Thanks,

Steve.