• Foo Bar (6/6) Mar 12 2019 Well, a snippet is worth a thousand words:
• Adam D. Ruppe (11/14) Mar 12 2019 Yes, it is correct behavior, though it does trip a lot of people
• Foo Bar (2/17) Mar 12 2019 Ah, okay. Thanks for the clarification.

Foo Bar <email example.org> writes:

Well, a snippet is worth a thousand words:
https://run.dlang.io/is/hjvMDO

I came across this strange behavior, however I am unsure as to 
whether this is correct behavior, or just an expected behavior of 
shadowing. It seems like there should at least be some sort of 
compiler error/warning for this.

Adam D. Ruppe <destructionator gmail.com> writes:

On Wednesday, 13 March 2019 at 00:27:02 UTC, Foo Bar wrote:
 I came across this strange behavior, however I am unsure as to 
 whether this is correct behavior, or just an expected behavior 
 of shadowing.

Yes, it is correct behavior, though it does trip a lot of people 
up.

Each variable set in a class declaration is independent. Lookups 
go for the first one they see up a chain from the static type.

Inside the override foo, it looks up and sees B.boolean. But 
outside, you cased to A, so it can only see A.boolean.

Object-oriented pattern here is typically to keep your member 
vars private and read/write through accessor methods instead, 
which can be virtual and thus be overridden in child classes as 
needed.

Foo Bar <email example.org> writes:

On Wednesday, 13 March 2019 at 00:50:35 UTC, Adam D. Ruppe wrote:
 On Wednesday, 13 March 2019 at 00:27:02 UTC, Foo Bar wrote:
 I came across this strange behavior, however I am unsure as to 
 whether this is correct behavior, or just an expected behavior 
 of shadowing.

 Yes, it is correct behavior, though it does trip a lot of 
 people up.

 Each variable set in a class declaration is independent. 
 Lookups go for the first one they see up a chain from the 
 static type.

 Inside the override foo, it looks up and sees B.boolean. But 
 outside, you cased to A, so it can only see A.boolean.

 Object-oriented pattern here is typically to keep your member 
 vars private and read/write through accessor methods instead, 
 which can be virtual and thus be overridden in child classes as 
 needed.

Ah, okay. Thanks for the clarification.