• Janice Caron (54/54) Mar 30 2008 Changing all the words for constancy in one fell swoop would result in
• Paul D Anderson (4/12) Mar 30 2008 I'm agnostic toward the "overnight" vs. "phased in" issue, but I agree w...
• Leandro Lucarella (11/12) Mar 30 2008 It's a nice plan, but overkill for an unstable version of the language

"Janice Caron" <caron800 googlemail.com> writes:

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?

Paul D Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:

Janice Caron Wrote:

 
 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?

I'm agnostic toward the "overnight" vs. "phased in" issue, but I agree with the
assumption that the const question is settled except for nomenclature/syntax. I
think Walter's FAQ make it clear that transitive const is the way forward in
his view (which I agree with).

That said, we've gone around and around on terminology. I don't mind the
current usage, though I dislike the extension of 'enum' for manifest constants.
But I'd really like to settle the question, wherever it ends up.

Paul

Leandro Lucarella <llucax gmail.com> writes:

Janice Caron, el 30 de marzo a las 13:32 me escribiste:
 Thoughts?

It's a nice plan, but overkill for an unstable version of the language
IMHO.

BTW, that's exactly how the *stable* compiler should evolve for me.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
PITUFO ENRIQUE ATEMORIZA CATAMARCA, AMPLIAREMOS
	-- Crónica TV