Christian Engström <christian.engstrom@glindra.org> writes:
[...], an algorithm that performs concept checks for concepts that it doesn't actually need is just that: faulty.
"David Abrahams" <dave@boost-consulting.com> wrote
The implementation is not faulty. The algorithm's implementation cannot be called faulty just because it exercises a part of the parameter's interface that's required by the algorithm's specification.
True, it's the specification that's faulty in that case, not the implementation as such.
You could make an argument that the specification is faulty because it only contains a concept "iterator" and not a less-refined concept "iterator that may not support the usual operator-> semantics".
If that is how the specification in STL is written, I am indeed making that argument. All the STL algorithms are guaranteed to work on containers of built-in types, such as a Container<int>, which does not even have operator->, let alone any particular semantics for it. If there is a "specification" somewhere that claims that operator-> must be defined in any particular way for the algorithms to work, even though this is obviously not true, then I consider that specification to be faulty.
I think it's unreasonable to expect every concept to be broken down to its bare minimum to avoid placing any unneeded requirements on parameters.
What an unusual position to adopt. What do you propose then, actual requirements plus 10%? Plus 20%?
Meta-comment: you seem to have little respect for the value of specifications.
If we are talking about "specifications" that do not accuratetely describe the actual requirements of the algorithm, I indeed have very little respect for them, which seems to be exactly the amount they deserve. But if we are talking about real, accurate specifications, I have the deepest respect for them. It is for this reason that I am so very interested in finding any cases where a proxy_iterator would not work properly, but an "ordinary" iterator would, so that I can add them to the specifications for the proxy_iterator.
But I agree, it's a point well worth keeping in mind, that since the proxy package is designed in a way that may not coincide with many people's expectations, it may possibly run a higher than normal risk of triggering latent bugs in various third-party components.
We're not talking about bugs, and we're not talking about third-party components. We're talking about standard-conforming implementations of the standard library.
Okay, so a more accurate way of describing the problem would be: "Due to a glitch in the formal specification for iterators in STL, algorithms are allowed to place semantic restrictions on the -> operator when it exists, even though the algorithm can never acutally use the operator in question, since is not actually required to exist at all. The proxy_iterator:s may not work with STL implementations that deliberately take advantage of this glitch to do over-reacing concept-checking for concepts that they do not actually require. It is not known if any such implementations actually exist or are in common use." /Christian