| |
 | Posted by Janice Caron |  Permalink Reply |
|
Janice Caron 
| 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?
|
