@api: One attribute to rule them All

[Joseph Rushton Wakeling via Digitalmars-d]

On 05/01/15 22:14, Zach the Mystic via Digitalmars-d wrote:
> I get a compiler error. The only way to stop it is to add unnecessary visual
> noise to the first function. All of these attributes should be something that
> you *want* to add, not something that you *need*. The compiler can obviously
> figure out if the function throws or not. Just keep an additional internal flag
> for each of the attributes. When any attribute is violated, flip the bit and
> boom, you have your implicit function signature.

Bear in mind one quite important factor -- all that alleged noise isn't simply 
about getting stuff to work, it's about promises that the function makes to 
downstream users.  You do touch on this yourself, but I think you have missed 
how your @api flag could go wrong.

> I suggest a new attribute, @api, which does nothing more than to tell the
> compiler to generate the function signature and mangle the name only with its
> explicit attributes, and not with its inferred ones. Inside the program, there's
> no reason the compiler can't continue to use inference, but with @api, the
> exposed interface will be stabilized, should the programmer want that. Simple.

IMHO if anything like this is to be implemented, the extra flag should be to 
indicate that a function is _not_ intended to be part of the API and that 
therefore it is OK to infer its attributes.

Here's the rationale.  Suppose that I have a bunch of functions that are all 
intended to be part of the public API of my project.  I accidentally forget to 
tag one of them with the @api attribute, so its attributes will be 
auto-inferred, but the function is still public, so downstream users will wind 
up using it.

3 months later, I realize my mistake, and add the @api attribute -- at which 
point downstream users' code will break if their code was relying on the 
unintended inferred attributes.

If on the other hand you take the assumption that attributes should by default 
_not_ be auto-inferred, and you accidentally forget to tag a function to 
auto-infer its attributes, that can be fixed without breaking downstream.

It's quite analogous in this respect to the argument about final vs. virtual by 
default for class methods.