Re: if (auto x = cast(C) x)
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 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).
One option is to use
https://dlang.org/library/std/algorithm/comparison/cast_switch.html
Re: if (auto x = cast(C) x)
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/
if (auto x = cast(C) x)
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).
