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

[Stewart Gordon]

"Nathan Reed" <nathaniel.reed at gmail.com> wrote in message 
news:fgg8hs$hon$1 at digitalmars.com...
<snip>
> As I've remarked in another thread, it makes absolutely no sense to me to 
> use invariant for the library string functions, for exactly this reason. 
> They used to be const, which enables them to work on any kind of string 
> the user might want to call them on (mutable, const, or invariant).

Exactly what I was thinking.

>> 1. A property .invariant, which just returns the reference as an 
>> invariant if it's already invariant, otherwise does the same as .idup. 
>> For this to work, the runtime would have to keep a record of whether each 
>> piece of allocated memory is invariant, which would interfere with the 
>> current ability to cast invariance in or out - but at what cost?
>
> Actually, this wouldn't need to have any runtime consequences, as the 
> invariantness-or-not of a thing is part of its static typing, so could be 
> determined at compile time.  Of course, something can be invariant even if 
> it's not typed as invariant (and undecidably so), but do we really need to 
> worry about that?  The .invariant property could simply return the array 
> if the array is typed as invariant, and return .idup otherwise.

I was thinking about the possibility of .invariant being able to detect 
whether a pointer or array reference typed as const refers to data that was 
created as invariant or not.

>> 3. Some concept of const-transparent functions.  One approach would be to 
>> enable a type modifier (or the lack thereof) to be used as a template 
>> parameter, with something like
>> ----------
>> 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?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.