Explicit instantiation of itk::Image fails with 5.2 when pixel type does not support operator==

[blowekamp]

With the additional of itk::Image::operator==, it is a new requirement for the Image's pixel type to support operator==. Previously, SimpleITK ( in some configurations ) had been explicitly instantiating the type: itk::Image<std::deque<itk::LabelObjectLine<2u>, std::allocator<itk::LabelObjectLine<2u> > >, 1u> because it was frequently used within the LabelMap module. With ITK 5.2 this results in a compilation error due to operator== not being supported. See SimpleITK/SimpleITK#1404 . While, in this case the explicit instantiation can just be removed, a more general solution in ITK would be good.

Do we want to explicitly require the pixel type to support the operator==, perhaps with a concept check?

Should the itk::Image::operator== be disabled when not supported by the pixel?

[N-Dekker]

@blowekamp Sorry, when I proposed itk::Image::operator==, I did not realize that some pixel types might not supports operator==.

However, it seems quite reasonable to me to require that a pixel type does indeed support operator==. For itk::LabelObjectLine it seems quite easy to add operator==, right?

[blowekamp]

However, it seems quite reasonable to me to require that a pixel type does indeed support operator==. For itk::LabelObjectLine it seems quite easy to add operator==, right?

Component in ITK are frequently are used in interesting and unexpected ways.

That would address this particular case. If that approach is followed, I'd recommend adding some type of concept check to the itk::Image.

[dzenanz]

A more meaningful error message from a concept check sound like a good solution.