www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - auto attribution pros/cons

reply 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.
Jun 28
next sibling parent reply 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).
Jun 28
parent 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.
Jun 28
prev sibling next sibling parent reply 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?"
Jun 28
next sibling parent 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.
Jun 28
prev sibling parent reply 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.
Jun 28
parent 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.
Jun 29
prev sibling parent 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.
Jun 28