Attribute inference for auto functions?

[Regan Heath]

On Tue, 16 Apr 2013 16:22:56 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

I read the whole thing and IMO this pull request is a good idea.

I think your last summary covers the various points well:
https://github.com/D-Programming-Language/dmd/pull/1877#issuecomment-16403663

Should the first step here be to fix the issue described in 2.1?  I agree  
with your reasoning that (b) seems a decent solution.  We don't want  
'auto' function bodies in .di files and /more importantly/ IMO interface  
definitions should be as precise as possible.

I would almost suggest that good working practice may be to use auto in  
the .d file, generate the precise .di then back-port the precise .di  
definition to the .d file once development was complete (for any given  
version of the library).

This would then make accidental changes to a library interface difficult  
because and change to the library source which conflicted with the now  
precise definition would be flagged by the compiler.  That is, unless  
you're doing something nasty with void* and cast or similar.

It seems the remaining complaint is the compilation speed issue.

Do people recompile .di files with every change?

I can imagine if you're in a development loop which involves updating a  
library, recompiling it, moving to a consumer of that library, updating  
that and recompiling, then testing the change, then looping back to make  
more changes, and so on.  In this case it is conceivable that a library  
changes might result in a .di change, which would then result in more  
recompilation right through.

But .. if the .di changes it will do so because the library interface has  
changed, and those changes are surely important to the consumer, aren't  
they?

Or, is there a sufficiently large sub-set of possible changes you could  
make to the library which are irrelevant to the consumer?

If that is the case, can .di generation from 'auto' leave these off the  
precise definition?  I mean, if we're saying they're irrelevant to the  
consumer of the library, why put them there in the first place, right?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/