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