[2.5] Failure to compile hybridutilities.hh
While I'm usually on Linux, I've tried to compile the core modules and a few others on a Mac to see if it'd work. In each case, I went with the 2.5 release branch.
When compiling dune/grid/io/file/dgfparser/dgfparser.cc, I hit the following error:
/Users/pipping/dune-sources/dune-common/dune/common/hybridutilities.hh:110:12: error:
type 'Dune::Std::integer_sequence<unsigned long, 0, 1, 2>' does not provide a
subscript operator
return c[i];
^ ~
The issue appears to be the following: elementAt
has a few specialisations and a fallback. I end up getting the fallback, namely
template<class Container, class Index>
constexpr decltype(auto) elementAt(Container&& c, Index&& i, PriorityTag<0>)
{
return c[i];
}
here, which doesn't work (and can't be expected to because there is no integer_sequence::operator[]
). Instead, this should be chosen:
template<class T, T... t, class Index>
constexpr decltype(auto) elementAt(std::integer_sequence<T, t...> c, Index&&, PriorityTa
g<1>)
{
return std::get<std::decay_t<Index>::value>(std::make_tuple(std::integral_constant<T,
t>()...));
}
Why is it not? The compiler (Apple LLVM version 8.1.0 (clang-802.0.42)) is invoked with -std=c++14
for me so that Dune::Std
should just be using std::integer_sequence
. Either way, a template specialisation for one apparently does not count as a template specialisation for the other.
My impression is that as long as we're providing Dune::Std::integer_sequence
, we should not be using std::integer_sequence
directly anywhere because (1) when we do, it entirely defeats the purpose of providing a fallback and (2) apparently it can lead to issues such as this one.
Indeed, if I replace each occurrence of std::integer_sequence
with Dune::Std::integer_sequence
in hybridutilities.hh, I can compile dune-grid (to me, this seems to be the right fix for the issue, too). I have not checked if this affects the master branch, too, since I'm more interested in 2.5; even if it didn't, I believe this should be fixed.