Why invariants in D 2.0 std.string?

Janice Caron caron800 at googlemail.com
Wed Oct 31 11:05:13 PDT 2007


I kinda like that.

I imagine the reasoning is that the library functions will go faster,
because they can be optimised better. Incidently, the find() family of
functions is defined in terms of "const const", not invariant. I don't
know why.

I know the whole const thing is going to change soon, but the current
definition of find is terrible confusing. It is:
    int find(in const const char[] s, dchar c);
    int find(in const const char[] s, in const const char[] sub);

Am I the only one who doesn't get "const const"?



I have a different question about std.string. Why are (most of) the
functions still defined only in terms of char.

The new function, munch(), is defined as a template type. It's signature is
    S munch(S)(ref S s, S pattern);

That's cool. It works for any kind of string. But the pre-existing
functions are still chars only. For example, tolower is still:
    invariant(char)[] tolower(invariant(char)[] s)

instead of, as one might hope:
    S tolower(S)(S s)

Of course, that said, I'm not completely sure how one would specify
that a template type must be tail-invariant! Maybe:
    invariant(C)[] tolower(C)(invariant(C)[] s)
?

Anyway, I would certainly have prefered all the string functions to
also work for wstring.



More information about the Digitalmars-d mailing list