On 8/9/17 5:54 PM, 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 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).
Just FYI, swift implemented something like this, and I find it
completely awful.
In Swift, they made all parameters to functions immutable (head
immutable), and if you want to modify the variable, you have to do:
var x = a
But for existing code that declared parameters to be mutable (so you
don't have to change too much), they allow:
var a = a
Which is terrible. I find this proposal would look equally terrible.
Sorry, I would be against it.
-Steve
