Draft: Remove the FieldVector<K,1> specialization

Summary

This MR removes the separate specialization of FieldVector<K,1> as a scalar type. Instead some functions are added to the primary template constrained to be only valid of SIZE == 1 case. Additionally, the interaction with scalar (field) types is being improved by allowing any type that is counted as IsNumber. Some alternatives were considered. Due to the implicit conversion operator of FieldVector<K,1> to const K&, several options lead to ambiguities.

Instead of using std::enable_if to constrain the functions to specific cases, this MR uses c++20 concepts and a requires clause. This makes the code more readable and the error messages better explaining what the problem is.

ToDo

• Requires an updated compiler toolchain with c++20 enabled.
• Extract some changes into separate MRs, e.g. !1492 (merged), !1493 (merged)
• Include changes from !1472 (merged) that makes DUNE_THROW usable in constexpr

mentioned in merge request !1387 (merged)

I like this. Not as much as getting rid of the size-1 special case altogether, but that would require a larger democratic process and consensus.

It seems your patch looks scarier than it actually is, because you are apparently doing some additional cleanup. Adding constexpr and northrow, e.g., should be uncontroversal. If that was presented as a separate MR it could probably go in right away.

Also, you seem be tightening some of the rules of what can be assigned to what. That, too, appears to be orthogonal to the size-1 specialization.

Why not remove this macro if it is such a pain? I can't think of a situation where throwing an exception here would be of any use. In my view any out-of-bounds array access here is certainly a bug, and the program may as well terminate directly.

Because this MR was not supposed to change the existing behavior.

Also, the DUNE_ASSERT_BOUNDS was original invented to do these bounds checks. Changing this in just one place here, would introduce another inconsistency in the dune-common code base. We should decide on doing this everywhere, or change the implementation of DUNE_ASSERT_BOUNDS, see also the discussion in !1388 (closed) and #110.

resolved all threads

@simon.praetorius , can you please rebase this MR?

added 48 commits

• 54b851a4...73c7034c - 47 commits from branch master
• 86b12cb1 - Remove the FieldVector<K,1> specialization

Compare with previous version

My impression is that this patch makes the code much shorter and simpler.

added 1 commit

• fbd7ddf5 - Make the generic specializations of DenseMatrixAssigner more safe

Compare with previous version

mentioned in issue staging/dune-functions#88 (closed)

added 1 commit

• 0fc3d48d - Fix assignment of matrices traits

Compare with previous version

mentioned in issue #373

added 1 commit

• 26633d1d - Use type properties defined before usage

Compare with previous version

added 67 commits

• 26633d1d...7958bd7e - 61 commits from branch master
• 8b429b93 - Remove the FieldVector<K,1> specialization
• c2f02c6d - Make the generic specializations of DenseMatrixAssigner more safe
• e5bbbf1c - Fix assignment of matrices traits
• 902c5a24 - Use type properties defined before usage
• e9bd00a5 - Merge branch 'issue/fieldvector-1-constructors-2' of...
• 7e63cb48 - Rewrite the FieldVector using concepts

Compare with previous version

added 1 commit

• ec4d05de - Fix a typo

Compare with previous version

added 1 commit

• cd53eb21 - Remove operator== for FieldVector in favor of DenseVector overload

Compare with previous version

added 1 commit

• d8449a35 - Replace assignable_from by is_assignable

Compare with previous version

added 2 commits

• f1000a26 - Add scalar concept
• 57952bae - Improve the documentation and use scalar concept

Compare with previous version

marked this merge request as ready

changed the description

requested review from @oliver.sander