Purity, @safety, etc., in generic code

deadalnix deadalnix at gmail.com
Tue Feb 19 22:00:00 PST 2013


On Tuesday, 19 February 2013 at 16:57:33 UTC, Zach the Mystic 
wrote:
> On Tuesday, 19 February 2013 at 08:25:08 UTC, kenji hara wrote:
>> 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
>
> I have no reason not to trust your great experience on this 
> matter. Is syntax sugar a possible solution?
>
> class A
> {
>     bool foo(in Object o) inout { return true; }
> }
>
> ... lowers to:
>
> class A
> {
>     bool foo(in Object o) { return true; }
>     bool foo(in Object o) const { return true; }
> }
>
> Or would that lead to extensive problems of its own?

The problem is now that you may overload on or the other function 
in derived classes. Such a surprising behavior is not acceptable 
IMO.

As discussed previously, I really wonder hy a const and non const 
version of a function can exists in a first place. What problem 
does it solve that isn't better solved by inout ?


More information about the Digitalmars-d mailing list