Attribute inference for auto functions?

[Michel Fortin]

On 2013-04-16 15:22:56 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> There's a discussion that may be of interest to the larger community: 
> https://github.com/D-Programming-Language/dmd/pull/1877

I agree attribute inference is needed. I don't think 'auto' is a 
suitable trigger. It'll encourage people to replace the return type on 
existing and new functions (making things more obscure) as a way get 
attribute inference.

Instead, all functions should have the benefit of attribute inference. 
I'd rather have a marker to prevent it when needed than have to opt it. 
For instance, if providing a stable API for a library is a concern, put 
that marker on those exported functions. Perhaps "export" could be that 
marker.

Unfortunately, that'll be slow. DMD will have to reprocess the function 
body for every called function transitively each time it compiles. The 
solution for that is to use .di files as a cache: in the process of 
creating a .di file the inferred attributes could be made explicit. 
Then disallow attribute inference for functions parsed from a .di file 
(so you can still provide a body for inlining). All this might pose a 
tricky cache-invalidation problem however: when a function somewhere 
changes you need to purge all the dependent di files *before* 
recompiling anything. :-/

Compilation speed is not a problem for functions with the "auto" return 
type because there are only a few of them. At least that's how it is 
right now. Allowing attribute inference only for this category of 
function might change those statistics after a few months in the wild, 
and then you'll have the compilation performance problems described 
above. Which might not be a bad thing, as then you'll need to overhaul 
the compilation model to fix this, and then you'll be able to enable it 
for all functions. ;-)

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/