On 2013-04-16 15:22:56 +0000, Andrei Alexandrescu
<seewebsiteforem...@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.for...@michelf.ca
http://michelf.ca/
