On Fri, Jan 16, 2026 at 3:03 PM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
One other thing. The advice to use a generic function template rather than a concrete function comes with a peril. Let me define one:
``` template <class ArrayDouble2D> auto substitute(ArrayDouble2D && l, ArrayDouble2D && r) { // ... l = r; } ```
There is no concept, so I can only guess what operations are allowed by a pseudo-concept ArrayDouble2D. I can assume that using the assignment is fine.
You are right, the implicit concept is quite loose here. Of course this wouldn't be a problem for `ArrayDouble2D const&` which is the original example in the documentation.
These are the concept that are implicit here (this is a placeholder syntax): template <class ArrayValueReextendableDouble2D, std::enable_if ... ArrayValueDouble2D::dimensionality == 2 && ArrayValueDouble2D::element == double && is_Reextendable(ArrayDouble2D) > auto fun(ArrayDouble2D && l) // this can be ArrayDouble2D& I guess template <class SubarrayReferenceUnreextendableDouble2D, std::enable_if ... SubarrayReferenceUnreextendableDouble2D::dimensionality == 2 && SubarrayReferenceUnreextendableDouble2D::element == double && !is_Reextendable(SubarrayReferenceUnreextendableDouble2D) (by exclusion) > auto fun(SubarrayReferenceDouble2D && l); Of course, this is very redundant, Subarrays are always (library) references and unresizable and Array are always values and resizable. Unfortunately I can't restrict this directly with the semantics of operator=, because it works on both cases. So I have to refer indirectly through the presence of .reextend , even if it is not used explicitly in the implementation of the function. And yes, operator= with preconditons is strange. That is the cost of working with this type of reference semantics, but without it no STL algorithm will work. What I can say is that value-semantics types do not have preconditions on operator=, while reference-sematic types in the library do have preconditions. (I think ARGUABLY that this is akin of saying with regular references that operator= is well defined in references if references are not invalidated, here is the same but with the .size(), so it is not completely out of the ordinary for operator= to crash on a reference --and imposible to detect--, the only difference is that we are so used to see this other kind of precondition on language references). Another type that has a precondition on assignment is `dynamic_array`, although it is owning. I consider assigning references of difference types a logic error in the code. I don't see other solution at the moment. I also can invoke some provenance arguments, for example (too strong) references taken from different arrays (or different views of the same array) shall not be assigned to each other. In same way that people can say that given pointers p and q coming from different allocators, p - q is undefined, if subarrays r and s come from different arrays then r = s is undefined. Another interesting question is whether any operator= can be noexcept. If the elements are trivial I can claim that operator= can never fail. On the other hand it has precondition (on sizes), so if I apply the Lakos' rule it can never be noexcept (in one case because of the precondition) in the other case (for array) because there is a possible allocation. I wish I could distinguish the too by the noexcepness, but I digress. Thanks, Alfredo