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

[Sean Kelly]

== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> Janice Caron wrote:
> > If there's enough interest, and if Walter approves, I could certainly
> > kickstart std.stringbuffer. Is that the right way to go? What do
> > people think?
> What it will do is provide a useful solution for those who really want
> to use mutable strings. I bet that, though, after a while they'll evolve
> to eschew it in favor of immutable strings. It's easier than arguing
> about it <g>.

I do agree with the notion that the majority of operations performed
on strings in a typical application do not modify the string in place.
However, in performance-oriented server applications, is it very
common to hold and reuse a mutable buffer between calls to avoid
the const of reallocation.  Assuming that references to this data are
passed around during the processing of a client request I would
fully expect the surrounding code to have no need to mutate the data.
However, because this is a reusable buffer, invariant is not a safe option
because the contents of the buffer will change for each request.  What
I would be inclined to do here is use const references to reflect this.

I've been thinking a lot about const and invariant recently and while
invariant strings seem quite handy for test code and the like, I have
not been able to think of a single production application where I would
actually be able to use them for the bulk of my string data, for the
reason mentioned above.  Rather, I would expect to use 'const'
everywhere because what I generally care about is preventing a caller
or callee from changing the contents of my data.  As for indicating
ownership, the following rule generally suffices:

    char[] getData(); // result is mutable -- ownership is transferred
    const(char)[] getData(); // result is const -- ownership not transferred

What I love about Steven's "scoped const" proposal is that it would allow
me to write a single instance of a library function that would work equally
well with any data, and the function would communicate its behavior within
the syntax.  Add "scoped const" to D 1.0 plus the ability to use 'const' in
all the places it can be used in D 2.0 and I'd be a happy camper.  Bonus
points for eliminating storage of static const (ie ROM-able) data and
dropping support for anonymous enum altogether.


Sean

P.S. The utility of 'invariant' for multiprogramming is a separate issue.  I
actually think it's unnecessary there as well, but don't want the discussion
to get off track by addressing this at all.  I'm merely adding this note so
no one will bring it up in response to what I said above.