Purity, @safety, etc., in generic code

[Steven Schveighoffer]

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