Good points @dzenanz, @blowekamp.
Some folks may not be aware, but it is important to keep in mind that ITK can be used with C++11 or higher and ITK does take advantage of newer standard features when available. Considering what VTK ended up with for C++11 adoption, ITK already takes advantage of nullptr
, override
, delete
, default
. Interestingly, VTK decided to limit auto
application for readability, and it was determined that shared_ptr
could not be used or mixed with existing library SmartPointer
's.
In terms of what other features come with ITK 5, it will depend on what resources are available and what contributions are made.
Setting aside features, I think a reasonable timeframe to strip out old deprecated code, mark code that is currently as “future deprecated” as “deprecated”, and migrate to new style / replace C++11 macros / update the style guide is the December 2018 at the earliest. We are still working on GitHub migration / finalizing the infrastructure for the June 2018 release.
Given the current state of compilers and operating systems, I think it is reasonable to make the policy in the future that we will support the major compilers for as long as the compilers and operating systems support them. OS’s and compilers are moving on much more quickly these days. And when a new major version of the compiler is released, they usually default to nearly the latest release of the C++ standard. Visual Studio 2017 defaults to C++14, GCC 7 is C++14, Clang 6 is anticipating a move to C++14 or later.