Always use concept checks?

Should we remove option ITK_USE_CONCEPT_CHECKING and always use concept checking in classes? Were there other use cases for this option besides inconsistent support in older compilers?

It used to be inconsistent support in compilers.

The only concern now is build time (?).

It may be reasonable to remove the option if build times of large projects like Python wrapping, Slicer, etc. are not significantly effected in their build time.

1 Like

Personally I wouldn’t mind if updates on ITK concept checking would be postponed until concepts are standardized in C++ (both the language and the std library). Looking at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018 (searching for “concept”), there still appears a lot of progress in that area. :grinning:

In the meantime, it seems to me that C++11 static_assert and <type_traits> could already be helpful to do similar checking. For example:

static_assert(std::is_convertible<int, TOutputPixelType>::value, 
    "IntConvertibleToOutputCheck");

Appears similar to:

itkConceptMacro( IntConvertibleToOutputCheck,
               ( Concept::Convertible< int, TOutputPixelType > ) );

From the class definition of HoughTransform2DCirclesImageFilter:

My 2 cents

Refactoring concept checks themselves is something we should do too. static_assert should be quite useful there, both for friendlier error messages and faster compile times.