On Tue, 16 Apr 2013 16:22:56 +0100, Andrei Alexandrescu
<seewebsiteforem...@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/
