On Mon, Mar 27, 2017 at 10:20 AM Aaron Ballman via Phabricator < revi...@reviews.llvm.org> wrote:
> aaron.ballman added a comment. > > In https://reviews.llvm.org/D31153#711287, @dblaikie wrote: > > > As I mentioned to Craig Topper recently on another review, generally > when implementing const and non-const overloads the non-const is > implemented in terms of the const overload (& const_casts away const on the > result). This ensures no UB if the const overload is called on a truly > const object. Even if there aren't any truly const Stmts today, I'd still > prefer the code be written so as not to assume they couldn't exist. > > > In practice, this is really hard to do because there's no such thing as a > const_iterator_cast operation to convert a const_iterator into an iterator, > unless you have the underlying container handy. Seems like it might be feasible to implement. Something along the lines of: struct StmtIterator : ... { private: StmtIterator(const ConstStmtIterator& RHS) : StmtIteratorImpl(RHS) { } friend StmtIterator const_cast(const ConstStmtIterator& RHS) { return RHS; } Something along those lines, I think? (StmtIteratorImpl has a protected ctor that takes a StmtIteratorBase - const or non-const, it doesn't seem to care - so StmtIterator can call that with a ConstStmtIterator and do the conversion?) > Since many of these uses do not have an underlying container (they're > often trailing objects), I'm not certain this is practical (though I agree > with the reasoning). Suggestions welcome, however. > > > https://reviews.llvm.org/D31153 > > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
