Mitigating the attribute proliferation - attribute inference for functions

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Mon Apr 13 07:09:32 PDT 2015


On 4/11/15 5:46 PM, Martin Nowak wrote:
> Sorry to open yet another topic.
>
> I'm repeatedly finding myself in situations where I write functions like
> this.
>
>      private @property bool empty() const @safe pure nothrow @nogc
>      {
>          return impl is null || !impl.count;
>      }
>
> This is obviously a joke, because the compiler very well knows the
> attributes and I don't need to guarantee them as part of an API.
> The situation is getting somewhat out of hands and we need to find a way
> to make attribute inference for functions feasible.

Have you considered the evolution of code?

For example, what if a @nogc-inferred function changes implementation 
and then uses the GC? The author of said function didn't care if it was 
@nogc or not, but the compiler helpfully makes it @nogc.

But now, the authors code works (again, he didn't care), but anyone 
using it that does use @nogc now cannot. The API changed but not on purpose.

Now, I understand you only want to apply this inference to internal 
functions. The problem is, there aren't very many of those. In fact, 
your sample above is not an internal function, so this whole idea is 
useless for it. I fear this would be a change with a lot of work, and 
very little benefit. It is highly dependent on how much "impl" functions 
you have, and most of the time, using some kind of private 
implementation is to make all the work done in one place, and have many 
public API functions access it. It seems like the wrong level of cost to 
benefit.

Sadly, I do not have a good answer. There are two purposes behind 
tagging a function, one is "because it is" and one is "because I want it 
to be". The first provides accessibility, the second is to double-check 
your API design against implementation. What we need is a way to say the 
first explicitly. We could do some kind of @inferattributes attribute, 
but I don't know if this is better or worse, and I don't know what this 
will mean. Does it mean "the attributes on this can change, beware"? Is 
that useful for a public API? At the very least, it can say "I guarantee 
the body of this function will always be available."

-Steve


More information about the Digitalmars-d mailing list