Inheritance of purity

[Jonathan M Davis]

On Sunday, February 26, 2012 16:30:44 deadalnix wrote:
> Le 26/02/2012 13:17, Jonathan M Davis a écrit :
> > On Sunday, February 26, 2012 13:02:14 deadalnix wrote:
> >> Thinking more about this, I did notice that I almost never do a const
> >> and a non const version of the same function when coding (either the
> >> functionality require const or it doesn't, so the const and non const
> >> version will do something very different, which is confusing).
> >> 
> >> Is it common ? If it is, it open the door to limiting override
> >> possibilities when it come to const.non const, with the advantage of
> >> being able to infer const in way more place than it is actually. I could
> >> expand about that.
> > 
> > It's common for some stuff. A classic example would be iterators (or
> > ranges). If you have a const reference or pointer to a container, then
> > the iterator (or range) that you get out of it must give you const access
> > to the elements, whereas a non-const reference or pointer to a container
> > should be able to give you an iterator or range with mutable access to
> > the elements.
> 
> Can't inout help us for such an issue ?

Probably. I'm not very well versed in inout though. But it _is_ likely that 
inout solves at least some issues which would require you to overload on 
const.

- Jonathan M Davis