Public outcry against new .init behaviour

[Deewiant]

With pre-1.017/2.001 .init:

typedef int foo = 1;
foo x = 3; // x.init is 3
foo y;     // y.init is 1

With new .init:

foo x = 3; // x.init is 1
foo y;     // y.init is 1

My question is, why? The only argument I've heard is consistency, such that
foo.property == typeof(foo).property, as in:

struct S { static int x; }
S s; // s.x == S.x, &s.x == &S.x

Yet there's no such consistency in place regardless of .init, and I really don't
understand this argument. What if x isn't static? S.x becomes an error.
Consistency lost!

The only way I can understand the above is that it's considered problematic that
.init is one of two properties which are valid for both a variable and its type,
and may give different results for each. If this is really that bad, consider
creating a new property, and make .stringof behave the same way. (Also, the
documentation at http://www.digitalmars.com/d/property.html still refers to the
old .init behaviour.)

There are significant arguments for the old behaviour of .init. The primary use,
in my experience, is to initialize variables to invalid values, and then one can
simply compare to .init to see if the variable has become valid. It's similar to
how static arrays simplify the C idiom:

#define FOO_LENGTH 3
int[FOO_LENGTH] foo;

In D, we can just write int[3] foo and use foo.length. However, with the new
.init, we're forced to use similar code:

typedef int foo = 1;
invariant foo X_INIT = 3; // "const" instead of "invariant" for D 1.0
foo x = X_INIT;

As opposed to what could be just foo x = 3 and x.init.

It's not deadly - I found 14 instances of such in about 7000 LOC (wc -l), and
they can be corrected - but it makes code noticeably uglier. This is one of
those small, simple bits of syntactic sugar which make coding in D fun and
productive. I want it back.

-- 
Remove ".doesnotlike.spam" from the mail address.