Jason House Wrote: > Denis Koroskin Wrote: > > > On Sun, 08 Mar 2009 06:44:48 +0300, Jason House > > <[email protected]> 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.
