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