const challenge

Sergey Gromov snake.scaly at gmail.com
Fri Feb 1 10:49:58 PST 2008


Sergey Gromov Wrote:

> Kris Wrote:
> > A need for such sugar in the language syntax would surely tend to 
> > indicate a notable flaw?
> 
> Yes you're right.  It's an attempt to avoid undefined behavior in
> specification in situations where the behavior is essentially defined.
> 
> 1. Anything you 'new' is basically unique:
>     new char[]
>     "a".dup
>     "a" ~ "b"
>     are all of type unique(unique(char)[]),
>     so as any immediate literal:
>     typeof(4) == unique(int)
> 2. Any non-unique type within a type casts away uniqueness:
>     typeof(["a", "b"]) == invariant(char)[][]
>     int[] x = [1,2,3];
>     int[][] y = [x];
>     typeof(y.dup) == int[][]
>     but typeof([[1,2,3]]) == unique(unique(unique(int)[])[])
> 3. unique(...) casts to invariant(...), const(...), or just ... implicitly
> with well-defined behavior.
> 4. There is no such thing as unique variable.
> 
> Did I miss something ?

Of course:

5. Only unique() casts implicitly to unique().
6. A function can have a unique() result, transitive.

SnakE



More information about the Digitalmars-d mailing list