if (auto x = cast(C) x)

[Moritz Maxeiner via Digitalmars-d-learn]

On Wednesday, 9 August 2017 at 21:54:46 UTC, Q. Schroll wrote:
> For a class/interface type `A` and a class `C` inheriting from 
> `A` one can do
>
>   A a = getA();
>   if (auto c = cast(C) a)
>   { .. use c .. }
>
> to get a `C` view on `a` if it happens to be a `C`-instance.
>
> Sometimes one cannot find a good new name for `c` while there 
> is no advantage of accessing `a` when `c` is available. D does 
> not allow to shadow `a` in the if-auto declaration for good 
> reasons.

How often do you need this? I wouldn't go as far as saying 
downcasting is (always) evil, but it can be indicative of 
suboptimal abstractions [1].

> How about relaxing the rule for cases like these, where the rhs 
> is the lhs with a cast to derived?
>
>   if (auto a = cast(C) a)
>   { .. use a typed as C .. }
>
> One can think of `a` being *statically* retyped to `C` as this 
> is a (strictly) better type information. Internally, it would 
> be a shadowing, but it does not matter as the disadvantages 
> don't apply (if I didn't miss something).

While I can't see an obvious semantic issue, I would vote against 
such syntax because it introduces more special cases (and in this 
case an inconsistency w.r.t. variable shadowing) into the 
language and I don't see it providing enough of a benefit 
(downcasting should be used rarely) to justify that.

[1] 
http://codebetter.com/jeremymiller/2006/12/26/downcasting-is-a-code-smell/