[Issue 16193] opApply() doesn't heap allocate closure
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Thu Jun 23 08:08:06 PDT 2016
https://issues.dlang.org/show_bug.cgi?id=16193
--- Comment #5 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to Marc Schütz from comment #4)
> Because of separate compilation, the compiler IMO _must not_ rely on the
> implementation details of the called function, it may only use the
> information available in the function signature. That's my understanding, at
> least: attribute inference must only happen for template and auto functions.
> Inlining is probably an exception, but I didn't enable that in this example.
This is somewhat OT, but separate compilation doesn't imply that. If the
implementation is available, it's available. If you change the implementation
between compilations, you're in for a world of hurt.
Consider that templates can be used with separate compilation, how would that
fare?
The reason D does not infer attributes for non-template non-auto functions is
because you *could* provide a .di file that just contains prototypes, and then
the inferred attributes are no longer correct. For a template or auto-return,
the function would be invalid, so that is why we can infer there.
In this case, however, we are talking about an optimization, and something
decided by the caller, not the callee. So whether to allocate a closure can
easily be decided by looking at all the code that will use that particular
delegate instance and seeing if it escapes. It need not modify or infer any
attributes of functions to achieve this.
--
More information about the Digitalmars-d-bugs
mailing list