Const, invariant, strings and "constant data need never be copied"

[Janice Caron]

On 11/3/07, Stewart Gordon <smjg_1998 at yahoo.com> wrote:
> >> T(char)[] doSomethingWith(typemod T)(T(char)[] param) {
> >>    ...
> >> }
> >
> > A proposal for doing something very much like this is already planned for
> > D 2.0 (it's in the WalterAndrei.pdf from the D conference a couple months
> > back).  It's called the 'return' storage class, which would make the
> > return value of a function take on the same constness or invariantness as
> > a parameter:
> >
> > const(char)[] doSomethingWith(return const (char)[] param) {
> >     ...
> > }
> >
> > What this does is makes the constness of the return value the same as the
> > constness of the argument passed to 'param', each time the function is
> > called.  You can do something similar with templates already, but you
> > can't make template functions virtual.  The function is type-checked with
> > the declared types for the parameter and return (in this case,
> > const(char)[]).
>
> This looks odd to me - you change the code declaring the _parameter_ type in
> order to effect a variation in the _return_ type?  And how would you use the
> type of parameterised constness within the body of the function?

I agree with Stewart here. (Actually, reading what's been read, I
agree with everybody, except possibly Walter and Andrei).

It makes much more sense to me to allow some kind of template-like
parameter whose value can be const, invariant or mutable.

Also useful would be stuff like
   is(a : const)
   is(a : invariant)
   is(a : mutable)
for compile-time decision-making.