Purity, @safety, etc., in generic code

[kenji hara]

I have said that "method const qualifier inference on class inheritance is
bad".

With 8138 or 8366, such inference suddenly add const qualifier to one of
overloaded functions, and changes the meaning of overload list. More than
worse, it may introduce newly relation between overloaded functions, and in
the worst case, it will add new forward reference problem.

class C : B  // or class C(T)
{
    void foo() { ... foo(10);  ... }
    void foo(int n) { ... foo(); ... }
}

For pure/nothrow/@safe inference, if a mutual dependency is found, the
attributes are inferred to impure/throwing/@system due to avoid forward
reference issue.
But, we cannot define such 'default qualifier' for const inference. So it
must raise  forward reference error if a mutual dependency is found. AND it
will break existing valid code.

And bug 8366 can allow to hijack derived class by base class. If a base
class add const qualifier to its method, it affects to the overload list in
its derived class, not only the method that directly overrides modified one.

We should avoid language features that is hijacking/fwdref error prone.

Kenji Hara

2013/2/19 deadalnix <deadalnix at gmail.com>

> On Monday, 18 February 2013 at 07:46:24 UTC, kenji hara wrote:
>
>> I think const must not be inferred for member function, because it affects
>> to the function overloading. For example, the const-ness for class method
>> will be inferred from base class overridden method with current compiler,
>> but it causes a serious problem.
>>
>> http://d.puremagic.com/issues/**show_bug.cgi?id=8366<http://d.puremagic.com/issues/show_bug.cgi?id=8366>
>>
>> Instead, you should declare two methods in generic code - one is mutable,
>> and another is const/inout.
>>
>>
> I remember mentioning overloading on const as a bad idea in the past. I
> don't really see the point of it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130219/826fc5c6/attachment-0001.html>