var.init change

[mwarning]

Myron Alexander Wrote:
> I am interested in the reason behind this change, if only to learn what 
> problems were introduced by such a concept.

From:
http://www.digitalmars.com/webnews/newsgroups.php?compose=reply&mid=55170

Walter Bright Wrote:

> Deewiant wrote:
> > 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.
> 
> I'll repost what I did earlier on this:
> 
> > Andrei made an argument that if one had:
> > 
> >     struct S
> >     {
> >         static int foo;
> >     }
> > 
> >     S s = ...;
> >     assert(s.foo == S.foo);
> > 
> > then, analogously:
> > 
> >     T t = ...;
> >     assert(t.init == T.init);
> > 
> > should hold as well. Consistency is a strong argument.
> 
> 
> I like the old behavior too, but with the increasing use of generic 
> code, I worry that the inconsistency is going to cause a lot of problems 
> in the future.

I think it's a nice feature, too.
But I'm doubtful about the inconsistency argument.
T t = ...; is initialized at run time, and it's value is also only known at runtime.
Therefor the compile time value is always null (or undefined when void was assigned at compile time).

So I would argue that there might be no inconsistency, only if you make the meaning of .init broad enough, so that it undoubtfully causes inconsistencies.

Am I wrong?