A time-delayed plan for renaming const flavors

Janice Caron caron800 at googlemail.com
Sun Mar 30 05:32:26 PDT 2008


Changing all the words for constancy in one fell swoop would result in
programs breaking in odd ways. Some programs would still compile, but
behave in unexptected ways.

So here's a plan to change things, one step at a time.

STAGE 0 : The current regime

STAGE 1 : The keyword "const" is deprecated in all positions, and the
keyword "in" is deprecated as a function parameter attribute. The
keyword "viewof" is introduced to take the place of both.

STAGE 2 :  The keyword "const" is made illegal in all positions,
though it remains a reserved word. The keyword "in" is made illegal as
a function parameter attribute.

STAGE 3 : We define a "POD" type as a type whose memory layout
contains no pointers-to-mutable, and no pointers-to-viewof. (They
/can/ contain pointers-to-invariant, but only if whatever is pointed
to is also POD).

Armed with this definition, we decree that if any declaration declares
a POD type to be /fully/ viewof, then the compiler transparently
retypes it to be fully invariant. Example:

    viewof int x = 42;
    writefln(typeof(x).stringof);

writes "invariant(int)", not "viewof(int)". This will become important
later on, as we shall see.

STAGE 4 : The keyword "invariant" is deprecated in all positions
except for class invariant declarations. The keyword "const" takes
over its functionality.

STAGE 5 : The keyword "invariant" is made illegal in all positions
except for class invariant declarations.

STAGE 6: We decree that if any declaration declares a POD type to be
/fully/ const, then it is a manifest constant. It occupies no storage,
and its address may never be taken. Example:

    const int x = 42;
    auto p = &x; /* ERROR */

If you really need the address taken, then you must instead declare:

    viewof int x = 42;
    auto p = &x; /* OK */

This is why step 3 was important.

STAGE 7: The keyword "enum" is deprecated everywhere it would not be
legal in D1.0. The keyword "const" takes over its functionality, as
described in stage 6.

STAGE 8: The keyword "enum" is made illegal everywhere it would not be
legal in D1.0.

At the end of this process, the flavors of constancy will have been renamed:

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

(and const and enum both now have the same meaning in both D1 and D2).

I don't know whether or not an eight stage transition is better than
an "overnight" change of everything all at once, but at least this
way, changes that break code will always give a compile error, and the
steps needed to fix things will be simple and straightforward at each
stage.

Thoughts?



More information about the Digitalmars-d mailing list