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
