http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
Gabriel Dos Reis <gdr at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gdr at gcc dot gnu.org
AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot
|com |gnu.org
--- Comment #5 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2011-05-17
15:04:48 UTC ---
(In reply to comment #2)
> To expand: *if* the '+' itself is allowed per the specs to return something !=
> std::valarray, and the specs only mandate std::begin and std::end overloads
> taking std::valarray& and const std::valarray& I don't see where is the bug in
> our implementation. Maybe a QoI issue? I'm not sure. Admittedly I haven't
> followed the recent discussion about ranges in any detail, I may be missing
> something.
LWG failed to resist the longstanding temptation to turn valarray into
yet another container. You can't turn it into an container and yet
make is possible for implementations to EFFECTIVELY exploit the lack
of aliasing guarantees. If looks like everytime I turn my back LWG
jumps tto do something to valarray.
Either we have a flood of begin/end functions decorated with __enable_if
stuff or we make it a defect in LWG.
Sigh.
