What to do when you want to add attributes to your class functions?

[RazvanN]

On Friday, 16 September 2022 at 12:42:40 UTC, Adam D Ruppe wrote:
> On Friday, 16 September 2022 at 09:25:58 UTC, RazvanN wrote:
>> However, now you are faced with a large breaking change 
>> because suddenly you force your users to respect these 
>> attributes. This seems like a severe limitation to me.
>
> It is *absolutely* necessary to maintain the integrity of 
> interfaces.
>

I completely understand why that is the case, it's just that it 
makes it
difficult to use both features together.

> see 
> http://dpldocs.info/this-week-in-d/Blog.Posted_2022_07_11.html#run-time-dispatch for some tangentially related discussion
>
>> The override is not even marked as @safe and the compiler does 
>> not indicate that the function is @safe because it overrides a 
>> safe function.
>
> The error message could perhaps point it out, but this behavior 
> is also quite useful, letting implementations usually just work.
>
>
>> The point is, there is no way for a library owner to satisfy 
>> both people that want attributes and people that don't.
>
> You could have two branches of the interface. It is always 
> allowed to add restrictions to child classes, so you could have
>
> class Base { void foo(); }
> class StrictBase : Base { void foo() @nogc pure etc; }
>
> then people use those. Or, you can have
>
> class Base {
>    int foo_strict() @nogc pure etc {}
>    final void foo() { }
> }
>

This works under the assumption that you have already created your
code with a thought to attributes. However, there is a ton of code
that is not attributed but could be.

> Though that gets weird if you wanted to override the other one 
> i still use final on purpose here cuz that's less weird than 
> having both and needing to choose one.
>
>> It just seems simpler to never use attributes at all (with 
>> classes).
>
> Or never use the attributes at all with anything. They don't 
> actually provide much value anyway.

Reasonable people could disagree.

>
>> However, now, if we mark the methods as @nogc we break 
>> downstream code (phobos as well) because suddenly those 
>> methods need to abide to new restrictions.
>
> In this case, either the overload or an outright breaking 
> change is the right thing to do. I find it very unlikely these 
> are actually overridden often. But the possible breaking of 
> error handling needs to be considered regardless of attributes.

The overload does not seem like a good solution to me. Right now 
I am making
the functions nogc, but what if in the future we could make them 
@safe (it's
just for illustrative purposes, I don't know if any of those 
functions could
be made @safe)? We create yet another overload?