Returning const? -- A potential solution

Jason House jason.james.house at gmail.com
Sun Mar 8 05:11:04 PDT 2009


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.



More information about the Digitalmars-d mailing list