Re: Partial retraction (was: Re: catcalls/convert)

	I sure don't. Void-safety is exciting.
	
Void-safety is a nice idea, albeit one sufficiently old that the only
"exciting" about it is seeing it adopted in a core language rather than
an annotation scheme.
(For example, the Java verifier ESC/Java -- now replaced by ESC/Java2 --
has offered this feature to Java programmers for quite some time, and
of course it has been offered by SPlint for C for even longer.)

I suppose I should prove my point about the age of this technique by
a citation:

    Hermes Language Experiences
    Willard Korfhage & Arthur P. Goldberg
    Software--Practice and Experience, Vol 25(4), 389-402 (April 1995)

    "To the best of our knowledge, complete compile-time checking of
     data initialization is unique to Hermes and its predecessor, NIL..."
    "Typestate checking prevents reading uninitialized data or
     dereferencing uninitialized pointers."
    "Hermes compilers use typestate checking to track the locations in
     the source code [where] a variable is uninitialized (and therefore
     may not be read), and where a variant is in the wrong case (and
     therefore may neither be read or written) and where a program value
     is unchecked (and therefore may not be instantiated.) ..."

Actually, the Hermes book (which I have not seen) came out in 1991.
And this 14+-year-old idea is an *advance* on what's proposed for
ECMA Eiffel.  "Exciting"?  To see _half_ an old idea adopted?

	I'm not so sure that it will invalidate any existing code, let alone 
	*every* use of a reference type. There's not much detail yet in ETL3 
	Chapter 24, "Eradicating void calls": only three pages. How can you 
	arrive at such a conclusion about something that hasn't been fully 
	described yet?
	
By reading what *has* been described, which states quite clearly that	
a type without an attachment mark -- which used to mean "something that
CAN be Void" -- will mean "something that CANNOT be Void".

Surely we can agree on the following points?
(1) Ensuring at compile time that as many calls as possible are void-safe
    is a Good Thing.
(2) If we were designing a language de novo, making the common case (I do
    NOT intend this argument to be Void) the easy one to express would be
    a Good Thing.
(3) Eiffel already exists; it is not being designed de novo but revised.
(4) When something changes from meaning "this could be Void" to meaning
    "this may not be Void" that is an incompatible change.

Thanks to having to take my daughter to the hospital today for an
unexpected followup to her sprained ankle, I no longer have the time
to write the message I meant to.  But let me give you the keyword,
so that if I _do_ get to write the message tomorrow you will want to read it.

    Diarthrognathus.