Purity, @safety, etc., in generic code
Steven Schveighoffer
schveiguy at yahoo.com
Fri Feb 22 11:31:55 PST 2013
On Fri, 22 Feb 2013 13:18:34 -0500, deadalnix <deadalnix at gmail.com> wrote:
> On Friday, 22 February 2013 at 17:25:58 UTC, kenji hara wrote:
>> 2013/2/23 deadalnix <deadalnix at gmail.com>
>>
>>> 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
More information about the Digitalmars-d
mailing list