Purity, @safety, etc., in generic code

[Zach the Mystic]

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?