assigment to null class object member compiled? is this a bug?

[dangbinghoo]

On Monday, 22 October 2018 at 15:51:03 UTC, Alex wrote:
> On Monday, 22 October 2018 at 01:39:48 UTC, dangbinghoo wrote:
>> On Friday, 19 October 2018 at 09:08:32 UTC, Vijay Nayar wrote:
>>> Technically the code you have is syntactically correct.  You 
>>> are permitted to create a class variable without assigning it 
>>> to a class object.  (Assigning it to a class object would 
>>> look like "A a = new A();")
>>>
>>> Which section of The D Programming Language book makes you 
>>> think this would not compile?  I have the book as well, but 
>>> I'm not quite sure what part of the book you're referring to.
>>
>> the section 6.2, which is
>> ---
>> A a;
>> a.x = 5;
>> ---
>>
>> the book explained this should be refused to compile.
>>
>>
>> thanks!
>>
>> --
>> dangbinghoo
>
> You are wrong, actually:
> In the book, site 179 it states:
> "If you try to access a non-static member of a reference and 
> the compiler can prove statically that the reference would 
> definitely be null, it will refuse to compile the code."
>
> But the compiler is not able to prove that the reference is 
> definitely null. At least in this case, with compiler, I think 
> of.
> That's why it called runtime error.

no, I'm not, the code

---
A a;
a.x = 5
--

is the example explaining that 'the compiler can prove statically 
that the reference would
  definitely be null, it will refuse to compile the code.'

and for `is not able to prove that the reference is definitely 
null` the books has another example code:

---
A a;

if (<condition>) {
   a = new A;
}

...

if (<condition>) {
   a.x = 43; // correct
}
---

I think Adam is giving a better reason: the envolving D now 
behaves different by default about the null flow catch with the 
book.

thanks!