• Bruce Carneal (27/27) Jun 28 2020 int afunc(int x) @nogc nothrow pure @safe { return x; } // fully
• kinke (7/8) Jun 28 2020 The main problem IMO is the API instability - an innocent-looking
• Bruce Carneal (3/11) Jun 28 2020 You can force "hard points" in an API by using explicit
• Ben Jones (3/6) Jun 28 2020 What about adding "auto" an attribute that means "infer
• Bruce Carneal (12/20) Jun 28 2020 Template functions with zero template arguments, ala
• Dennis (3/5) Jun 28 2020 You can already make the return type auto, which will also infer
• Ben Jones (3/8) Jun 29 2020 True, but you could imagine wanting to be explicit about the
• rikki cattermole (14/14) Jun 28 2020 I've had the same idea regarding auto inferring. A lot of us did.

Bruce Carneal <bcarneal gmail.com> writes:

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.

kinke <noone nowhere.com> writes:

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).

Bruce Carneal <bcarneal gmail.com> writes:

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.

Ben Jones <fake fake.fake> writes:

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?"

Bruce Carneal <bcarneal gmail.com> writes:

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.

Dennis <dkorpel gmail.com> writes:

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.

Ben Jones <fake fake.fake> writes:

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.

rikki cattermole <rikki cattermole.co.nz> writes:

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.