On Fri, 29 Apr 2022 at 21:09, Marios Staikopoulos <marios_at_[hidden]> wrote:

> Okay I see, but to me this is really our (the programmers) fault, it
> should have been a requirement of Iterator to be move assignable/copyable
> in the first place – the code we have written has made implicit
> assumptions, when the Iterator concept should have been more explicit in
> its requirements.
>

Perhaps. But what if someone else wrote the concept, and they don't feel
like tightening the constraints? Adding std::copyable/std::movable
everywhere is not going to make you popular.


> If I understand correctly the issue is more of that IterationAlgorithm as
> a concept doesn’t actually know if Iterator is copyable, because such a
> constraint was not specified, yet we invoked a copy/move of iterator in the
> definition of apply.
>

Not quite; IterationAlgorithm would be fine for an algorithm taking its
arguments by const reference. It's IterationAlgorithm_Impl that takes its
arguments by value.

I think the simple solution would be to have it check if Iterator defines
> such a constraint, and if not simply error – something like an error
> saying, “Expected Iterator to be copyable, but no such constraint was
> defined”. After all, we are implying a constraint on a type, and it should
> be trivial to check that we satisfy that constraint. I would think that
> would be better than just lazy-evaluating much later.
>

Maybe, in simple cases. What about disjunction (alternation)? - which
alternate should the compiler choose? What about conditionals? - firstly,
what should the compiler choose for the predicate, and secondly, how is it
to know that at least one branch must be chosen? Especially if the
conditional is transformed to material implication in DNF; is it supposed
to have a sequent calculus solver? What of constraints expressed via class
or variable templates - as I said previously, the compiler can't tell when
those are intended to be specialized by the user and when they aren't.