"Gottlob Frege" <gottlobfrege@gmail.com> writes:
Top posting because I'm going to remark about this thread in general, but this message is a fine example.
Andy seems to be speaking (mostly) about int_<>, integral_c, etc (I'll just say the incorrect 'int<>') and plus; David is talking about transform.
I think, but can't say for sure, that Andy wants plus to work 'as expected' ^^^^^^^^^^^^^^^^^^ and always return int<>, not just 'concept-identical' to int.
Andy, please take note: what you want is still unclear to people other than me. Since "as expected" is vague, and your statement seems a little too sweeping, I'll say it this way: I (Dave) think, but can't say for sure, that Andy wants plus to always return an int_ specialization when all the inputs are specializations of int_. I think, but can't say for sure, that he also wants a different specification for the behavior of plus, and all the other arithmetic operators.
Maybe it does, I'm not sure. And/or he wants transform ***when applied to int<> with plus, etc*** to return int<>.
David, says, that ***in general*** transform can't make the return type "match" (in Andy's stricter sense) the inputs.
Maybe it could for the special case of int<>? IMO, that would be quite hard, as the point of the templates is to be general.
I don't think we can do it. However, it's certainly possible to make the *elements* of the resulting container be int_ specializations whenever the operation has the form: transform<s1, s2, op<_,_> > where s1 and s2 contain only specializations of int_ and op is an MPL arithmetic operation. Whether making that so is worth the costs or not, as far as I'm concerned, remains to be seen. I'd need to see code, and see evidence that this issue is actually the source of Andy's difficulties with compilation speed. And of course, Aleksey would need to render final judgement as the MPL maintainer. -- Dave Abrahams Boost Consulting www.boost-consulting.com