Returning const? -- A potential solution

[Jason House]

Jason House Wrote:

> Denis Koroskin Wrote:
> 
> > On Sun, 08 Mar 2009 06:44:48 +0300, Jason House <jason.james.house at gmail.com> wrote:
> > 
> > > The ugly const thread got me thinking about the old problem of returning  
> > > an
> > > input while preserving const safety.  I have an idea that seems
> > > reasonable...
> > >
> > > In a nutshell, I'm thinking that const(T) should be a base type for T,
> > > immutable(T) and return(T).  return(T) is treated in a read-only fashion,
> > > just like const(T) and immutable(T). Here are some of the key things I  
> > > think
> > > this achieves:
> > >   * Input arguments are never mutated
> > >   * Use of input parameters in calls to functions as const(T) is 100%  
> > > legal.
> > >   * Temporary variables can legally be defined and used
> > >   * Calling other functions that return return(T) is allowed
> > >   * No code duplication
> > >   * No code bloat (compiler only needs to generate one version of the  
> > > code)
> > >   * Functions can be virtual
> > >
> > > Let's take a relatively simple example: max
> > >
> > > return(T) max(return(T) a, return(T) b){ return (a>b)?a:b; }
> > >
> > > When max is called, the compiler would examine the inputs for a and b to
> > > determine what the true type for return(T) is from the callee's
> > > perspective...  So a call with T and immutable(T) would use const(T) as  
> > > the
> > > perceived return type while an argument of T and T would use T as the  
> > > return
> > > type.
> > >
> > > At the call site, the compiler would ensure type safety of how the return
> > > type is used.  Within max, the compiler would ensure that the arguments  
> > > are
> > > either treated as const(T) in function calls but not mixed with with  
> > > types
> > > T, const(T), or immutable(T)
> > >
> > > PS: The return(T) notation is an arbitrary one for the purposes of this
> > > post.  We need a technical solution before worrying about the color of  
> > > the
> > > bicycle shed
> > >
> > 
> > How about this one?
> > 
> > class Foo {
> >     T value() {
> >         return _value;
> >     }
> >     T value() const {
> >         return _value;
> >     }
> > }
> 
> My proposal did not handle that. I wasn't thinking of that case.
> 
>  
> > You suggest turning it into:
> > 
> > return(T) value() {
> >     return _value;
> > }
> > 
> > Which is fine but it doesn't say anything about constness of 'this'.
> > 
> > In fact, you propose *exactly* the same thing I've been proposing multiply times in past under a different name, though:
> > 
> > sameconst(T) max(sameconst(T) a, sameconst(T) b) {
> >     return (a > b) ? a : b;
> > }
> > 
> > class Foo {
> >     sameconst(T) value() sameconst(this) { // return value has the same constness as 'this' (mutable, const or immutable)
> >         return _value;
> >     }
> > }
> > 
> > The constness is automatically propogated based on parameters. For example,
> > - sameconst(T) == T if all the parameters are mutable
> > - sameconst(T) == immutable(T) if all the parameters are immutable
> > - sameconst(T) == const(T) otherwise
>  
> 
> I'll take another look at your proposal. I thought of sameconst as a type alias rather than a typedef. I was mostly thinking of how this problem could be handled by the type system.

Maybe my web searches are failing me, but all I found was your posts in the "equivalent functions" thread. The details there were sparse. In that thread, your first post did not support sameconst(this), but was added a bit later. As far as I can tell, it died with Andrei posting he felf his solution was more general. I hated Andrei's reuse of typeof.