On Fri, 22 Feb 2013 13:18:34 -0500, deadalnix <[email protected]> wrote:
On Friday, 22 February 2013 at 17:25:58 UTC, kenji hara wrote:
2013/2/23 deadalnix <[email protected]>
On Friday, 22 February 2013 at 15:32:42 UTC, kenji hara wrote:
Yes, then the B's definition should raise "mutable A.foo() is not
overridden but hidden in B" (but doesn't because of bug 8366).
I don't really understand why adding a special case for something that
has
no real use case.
In old age, it had thrown HiddenFuncError in runtime, and some years
ago,
it had been changed to compile-time error.
It is one of design in D to avoid unintended method hiding issue.
This whole overload on const (note overload, not override) has been
introduced in the first place to solve problem that inout now solve in a
superior way.
inout does not solve the problem. A non-const function is allowed to
modify the state of the object, a const or inout version is not.
If inout is used on a parameter (including this) but not on the return
value, it is equivalent to const. The problem it solves requires return
values (notably missing from all the examples in this discussion), and it
requires that they be the same type.
It is probably rare to have both a const and non-const overload, that is
true, but it is not up to D to decide what design is best. We should take
the most flexible approach, and allow designers to come up with whatever
ideas they like. I don't think there is any significant extra work
required to support const method overloads in the compiler, in fact it
would be a more significant change to make that an exception.
-Steve
