const

Janice Caron caron800 at googlemail.com
Fri Mar 28 10:37:18 PDT 2008


On 28/03/2008, Oskar Linde <oskar.lindeREM at ovegmail.com> wrote:
> I called const/invariant "type meta qualifiers". They are not part of
>  the type but carry type meta information. It makes sense that you are
>  able to pass the type meta qualifiers to templates that make use of
>  them. There is an analogue with how templates today by default strip the
>  type meta qualifiers.

I think that your "orthogonal const proposal" is a good one, but I
also think we'd need to express it in different language, or it won't
be understood. What you call "type meta qualifiers", Walter calls
"part of the type". We all gotta speak the same language. :-)

So here's how I think it should work. Note that this is very similar
to your proposal, but I'm using different words for things. I'm also
using the convention:

>     BEFORE -> AFTER
>     const -> in
>     invariant -> const
>     enum -> const

OK, here goes - Janice's rewrite of Oskar's orthoganal const proposal.
Tell me if you wildly disagree.

    const int a;
    writefln(typeof(a).stringof); // const(int)

    const(int) b;
    writefln(typeof(b).stringof); // const(int)

    in int c;
    writefln(typeof(c).stringof); // const(int)

    in(int) d;
    writefln(typeof(d).stringof); // const(int)

...but...

    in(int)[] e;
    writefln(typeof(e).stringof); // in(int)[]

Basically, the trick is, a little bit of compiler magic happens,
whereby if a declaration declares a POD data type to be /fully/ "in",
then the type is magically changed to "const".

The second bit of compiler magic is that if a declaration declares
something to be /fully/ "const", then the object is deemed to be a
manifest constant. Thus:

    struct S
    {
        int x;
        const n = 10;
    }
    writefln(S.sizeof); // 4

...but...

    struct T
    {
        int x;
        in n = 10;
    }
    writefln(S.sizeof); // 8

Those little compiler reinterpretations of things declared fully const
or fully in, I believe, achieve the same thing as your orthogonal
const proposal, but they do so without giving the const system a
complete overhaul.

What do you think?



More information about the Digitalmars-d mailing list