const challenge

[Janice Caron]

On Feb 1, 2008 4:55 AM, Kris <foo at bar.com> wrote:
> Steve - some D2 questions for ya:
>
> Taking an example related to the
> discussion, and if I understand correctly, the variations on Unique!(T) are
> little more than attempts to hide a cast() operation under a sugary coating,
> right?

Yes.


> A need for such sugar in the language syntax would surely tend to
> indicate a notable flaw?

It indicates a difficulty, yes. If something is invariant(T), then it
/may/ be in a read-only segment, and so modifying it is undefined.
That's fair enough. The thing is though that one can create a buffer
full of stuff on the heap or the stack and then cast it to invariant.
(That's what assumeUnique() does - it's more or less template sugar
for cast(invariant)). Now you can pass all those objects to functions
that take invariants, no problem. (At least, no problem if you don't
mind explicit casts. Some people object to them).

Unfortunately, it does have a negative consequence, which is
exemplified in concatenation. To get a mutable buffer when
concatenating, you have to do something like this:

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

This is known to be safe. Unfortunately, the D specification says that
casting away invariance is undefined, so strictly speaking, one
shouldn't do it. Perhaps, in the future, Andrei may come up with some
clever library template to hide the cast, but it will still be there,
under the hood.

So the advantage of the Unique!() type would be that concatenation of
strings could be allowed to return Unique!(char)[], which would mean
that, together with other changes like implicitly casting all the
supplied arguments to const, one would then be able to write:

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

so you wouldn't necessarily actually /see/ the Unique!() types -
they'd just be there to make the code compile.


> As far as the example api-style goes, here's hoping that this will work
> correctly in D2:

Everything works correctly in D2. The question is, will it work as
expected? Will it provide the right API to allow calling code to use
it? Will it demand additional explicit casts?

If the philosopy is "explicit casts are bad", then what we have right
now is not sufficient.

> <snip>
> yes?

I don't see anything wrong with anything you said. It just doesn't
provide the right API to interface with higher layers, that's all.
Some functions will call this like

    string result = other ("foo" );

and get a compile error. Sure - there are workarounds. That's really
the whole point of this thread though.