int afunc(int x) @nogc nothrow pure @safe { return x; } // fully attributed
int func(int x) { return x; } // a vanilla function
int tfunc()(int x) { return x; } // trivially templated

int main() @nogc nothrow pure @safe {
    // return afunc(0); // works
    return tfunc(0); // also works
    // return func(0); // fails to compile
}

Since tfunc() works today in the above, we know that much of the machinery
for "auto attribution" exists.  What are the pros/cons of enabling
auto attribution for vanilla functions?

Here are a few cons:
1) Some additional complexity in the compiler.  How much?
2) Some additional complexity in IDEs.  How much?
3) Could expose additional challenges for separate compilation.

Here are a few pros:
1) Extends the "it just works" envelope.
2) Allows explicit attribute requirements to move to a higher level.
3) Enables wider code reuse.
4) Removes clutter. (minor but who loves attribute soup?)
5) Lessens the importance of language level attribute defaulting.

Corrections to the above?  Better terminology?  Other pros/cons?

Note: the auto attribution idea is not original, I've just not seen it reviewed.

On Sunday, 28 June 2020 at 18:39:13 UTC, Bruce Carneal wrote:
> Other pros/cons?

The main problem IMO is the API instability - an innocent-looking change for a little leaf function may impact a huge number of callers, which e.g. affects D symbol name mangling. And a function f may become @safe when the last @system callee is, which might enable unwanted bounds checks for f with -release (and without additional -boundscheck=off).

On Sunday, 28 June 2020 at 21:44:45 UTC, kinke wrote:
> On Sunday, 28 June 2020 at 18:39:13 UTC, Bruce Carneal wrote:
>> Other pros/cons?
>
> The main problem IMO is the API instability - an innocent-looking change for a little leaf function may impact a huge number of callers, which e.g. affects D symbol name mangling. And a function f may become @safe when the last @system callee is, which might enable unwanted bounds checks for f with -release (and without additional -boundscheck=off).

You can force "hard points" in an API by using explicit attribution, just like today for templated functions.

On Sunday, 28 June 2020 at 18:39:13 UTC, Bruce Carneal wrote:
> Corrections to the above?  Better terminology?  Other pros/cons?
>
> Note: the auto attribution idea is not original, I've just not seen it reviewed.


What about adding "auto" an attribute that means "infer attributes?"

I've had the same idea regarding auto inferring. A lot of us did.

Nobody has gone forward with a DIP yet, and I'm time starved atm to do an attempt myself.

My solution is quite simple and cheap to implement.

Start with all attributes applied if you have a body.
If you hit something that "could be" anti, you turn off that attribute.

You can do this very early on, without semantic analysis.

False positives are a good thing I think. It forces you to think about it.

On another note, something I realized was that writing @safe or @system yourself for anything but alias's should be a big warning sign. The only one you should be doing is @trusted.

The .di generator could be used to emit annotated code, not just the subset known as a di file. So there are a few good possibilities with this approach that needs testing I think.

On Sunday, 28 June 2020 at 22:29:01 UTC, Ben Jones wrote:
> On Sunday, 28 June 2020 at 18:39:13 UTC, Bruce Carneal wrote:
>> Corrections to the above?  Better terminology?  Other pros/cons?
>>
>> Note: the auto attribution idea is not original, I've just not seen it reviewed.
>
>
> What about adding "auto" an attribute that means "infer attributes?"

Template functions with zero template arguments, ala
 int tfunc()(int x) { return x; },
are pretty close to that idea already.

A difference between auto attribution and "template auto" is that the latter adapts to its surroundings while the former would go hard over to different defaults when the attributes in question are machine provable e.g: @safe pure nothrow.

As proposed auto attribution would bias towards safety but would, as kinke notes, cause some programs to run slower until explicit performance attribution was put in place.  Not a "breaking" change exactly but a "performance breaking" change.

On Sunday, 28 June 2020 at 22:29:01 UTC, Ben Jones wrote:
> What about adding "auto" an attribute that means "infer attributes?"

You can already make the return type auto, which will also infer attributes.

On Sunday, 28 June 2020 at 23:06:25 UTC, Dennis wrote:
> On Sunday, 28 June 2020 at 22:29:01 UTC, Ben Jones wrote:
>> What about adding "auto" an attribute that means "infer attributes?"
>
> You can already make the return type auto, which will also infer attributes.

True, but you could imagine wanting to be explicit about the return type and still get attribute inference.