Is all this Invarient **** er... stuff, premature optimisation?

[Janice Caron]

2008/4/28 Me Here <p9e883002 at sneakemail.com>:
>  Ack! That's horrible. Instead of using the information I have, the
>  offset and length of the slice I want to manipulate, I have to derive
>  two offset/length pairs to the bits I do not want to do anything to.

Not necessarily. Instead of

    a = a[0..2] ~ "XXX" ~ a[5..$];

you could do

    char[] tmp = a.dup;
    tmp[2..5] = "XXX";
    a = assumeUnique(tmp);

(I forget which module you have to import to get assumeUnique). But
what you mustn't ever do is cast away invariant.


>  1) Whatever happened to polymorphism?

What's polymorphism got to do with anything? A string is an array, not a class.


>  So, if I assign the results of a string library function/method to a
>  mutable variable (Just a variable really. An invariant variable is a
>  constant!), then it should be possible (*IS* possible) to recognise
>  that and return an appropriate result.

Functions don't overload on return value.


>  The idea that runtime obtained or derived strings can be made truely
>  invariant is purely theoretical.

But the fact that someone else might be sharing the data is not.

>  But one of the
>  major attractions of D over C/C++ is its built-in string types

D has no built in string type. string is just an alias for invariant(char)[].

>  If everytime I want to use one
>  of these library calls, I have to cast my mutable string into and
>  invariant and then cast the result back to mutable

That's one approach. Another is don't try to treat strings as mutable.