Universal Function Attribute Inference

[zopsicle]

On Monday, 18 March 2024 at 10:30:28 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
>
> On 18/03/2024 12:12 PM, Timon Gehr wrote:
>> On 3/9/24 22:47, Richard (Rikki) Andrew Cattermole wrote:
>>> On 10/03/2024 10:26 AM, ryuukk_ wrote:
>>>> If there is a significant build penalty, than i hope it's 
>>>> opt-in, i personally do not use any of the attributes
>>>
>>> It shouldn't be significant.
>>>
>>> It is a minor cost as things go, no reason to start thinking 
>>> opt-in at this stage.
>> 
>> Really? This proposal requires full semantic analysis of any 
>> imported function. It is only minor in certain build setups. 
>> (E.g., when the project is compiled in a single invocation.)
>
> I am assuming that you generate .di files every time and use 
> that for importing, not the .d files.
>
> These days I'm leaning quite heavily towards projects using .di 
> files for intermediary steps, due to distribution reasons with 
> shared libraries.
>
> It's already impossible to keep bindings to D code up to date 
> manually, I tried pure was a killer on that idea.

One of my favorite features of D is its compilation model and in 
particular the ability to import from source files directly. This 
simplifies fast incremental parallel builds by not requiring a 
separate step to extract the interface of a module, or worse, 
requiring that modules are compiled in topological order.

C++20, Fortran, and Haskell modules and Rust crates work the 
other way; they require interface files to be generated for their 
compilation units before they can be imported. Consequently they 
do not integrate well with traditional build systems.

I personally don't mind maintaining the attributes by hand, but I 
understand other people would gladly trade convenience for build 
simplicity and performance. Perhaps the compiler could be 
configured to infer attributes on functions from certain modules 
and not others, catering to both use cases.