const challenge

[Janice Caron]

On 2/2/08, Walter Bright <newshound1 at digitalmars.com> wrote:
> There are some research papers about unique as a type qualifier, and it
> was toyed around with for a while with D. The trouble with it was:
>
> 1) complexity (yet another type qualifier)
>
> 2) it still never was quite able to get rid of all the interesting cases
> where a cast(invariant) (i.e. at some point trust the user) was needed
>
> 3) it was hard to understand
>
> 4) its utility seemed very limited

Yep, you're spot on the nail. Nobody can argue with any of those
points (except possibly (1), but we can go into that elsewhere if
needed).

Still - nobody here was suggesting unique "on a whim". Rather, it was
to solve a class of problems, the most obvious of which is to allow
the following to compile:

    string s;
    char[] t;
    char[] u = "hello" ~ s ~ t;

It could well be that we don't need unique, but you are always going
to get people complaining that they have to do:

    string s;
    char[] t;
    char[] u = "hello".dup ~ s.dup ~ t;

or

    string s;
    char[] t;
    char[] u = cast(char[])("hello" ~ s ~ cast(invariant(char)[])t);

The former doesn't look too bad but has unnecessary casts; the latter
looks ugly and is error-prone.

It's not just concatenation. There's a whole class of similar
functions which are likely to cause similar headaches, and cause
people to be critical of the whole const system.

Without unique, you're going to have to convince people that
superfluous dups are really OK. Maybe that's the way to go. Maybe
making new and gc collection really, really fast might do that?