Paul Backus kirjoitti 24.5.2024 klo 18.04:
> 
> I should emphasize that the ability to import directly from .d files is not going anywhere, even if this proposal is accepted. The .di files would function purely as a cache to improve performance, and generating them would never be required.

True. Still, I feel it's important we retain an easy way to *not* infer the attributes, even when available. For performance reasons like Walter wrote, but also to make sure the client code will not depend on attributes the library wishes to possibly remove in the future.

I'm pretty neutral on whether inferring everything by default is a good choice, but I'm saying that regardless of whether it is the non-default option should be easy to pick. Only one keyword per symbol, or several for a group of them.

On Wednesday, 20 March 2024 at 23:59:09 UTC, Paul Backus wrote:
> On Monday, 18 March 2024 at 10:30:28 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> I am assuming that you generate .di files every time and use that for importing, not the .d files.
>
> Yes, this is one possible mitigation.
>
> The main downside of this is that .di files don't include function bodies, so you lose access to cross-module CTFE. Although I guess we could add a compiler switch to include function bodies in .di files.

The other problem is inlining. It's what's kept me from always using .di files aided by the build system. I've thought of only doing that for debug builds though, since as I've stated multiple times producing a final binary is boring and all I really care about is running my tests as fast as possible.