Will there be a deprecation cycle for the proposed change? Our org still
uses Debian Jessie and we do not see ourselves off that before EOY.

On Mon, Feb 12, 2018 at 8:38 AM, James Peach <jpe...@apache.org> wrote:

>
>
> > On Feb 11, 2018, at 10:33 PM, Michael Park <mcyp...@gmail.com> wrote:
> >
> > On Sun, Feb 11, 2018 at 6:00 PM James Peach <jpe...@apache.org> wrote:
> >
> >>
> >>
> >>> On Feb 9, 2018, at 9:28 PM, Michael Park <mp...@apache.org> wrote:
> >>>
> >>> I'm going to put this up for a vote. My plan is to bump us to C++14 on
> >> Feb
> >>> 21.
> >>>
> >>> The following are the proposed changes:
> >>> - Minimum GCC *4.8.1* => *5*.
> >>> - Minimum Clang *3.5* => *3.6*.
> >>> - Minimum Apple Clang *8* => *9*.
> >>>
> >>> We'll have a standard voting, at least 3 binding votes, and no -1s.
> >>
> >> +0
> >>
> >> What’s the user benefit of this change?
> >>
> >
> > Some of the features I've described in MESOS-7949
> > <https://issues.apache.org/jira/browse/MESOS-7949> are:
> >
> >   - Generic lambdas
> >   - New lambda captures (Proper move captures!)
> >   - SFINAE result_of (We can remove stout/result_of.hpp)
> >   - Variable templates
> >   - Relaxed constexpr functions
> >   - Simple utilities such as std::make_unique
> >   - Metaprogramming facilities such as decay_t, index_sequence
>
> Are these all internal though? Maybe move captures could yield some
> performance improvements?
>
>


-- 
Cheers,

Zhitao Li

Reply via email to