Trying to use Mir ion, its a perfect example of the failure of D's attribute system

Hipreme msnmancini at hotmail.com
Fri Jan 20 21:23:29 UTC 2023


On Friday, 20 January 2023 at 19:18:23 UTC, Walter Bright wrote:
> In general, yes, moving towards attribute inference for 
> ordinary functions rather than just templates is where we want 
> to go.
>
> The reason it isn't done currently is because it makes .di 
> declarations incompatible with the .d definitions.

.di needs to become a lot better before impacting some kind of 
decision:

1. It needs a specific coding style to improve its output, such 
as writing your import inside the functions itself, though it 
should only expose what is really needed. Read that as classes, 
interfaces, types. Unless the user don't public import constants 
or functions, there's no reason to it be included in output, 
unless present in a template.

2. It could be used to do CTFE caching. As far as I understand, 
it is not possible to do that right now. But it would make a huge 
gain to the D community and would make it a lot more appealing.

3. The inference could be passed to the .di files at generation 
time. That would mean:
```d
int add(int a, int b){return a+b;}
```
Could easily be output to the .di as:
```d
@safe pure nothrow @nogc int add(int a, int b);
```

This could even save time in the .di usage as it would save the 
work of needing to do any kind of inference in library code.

This is things I could think out of the box. I would say that we 
are lacking tooling support for .di too. I don't think dub 
integrates nicely with .di files, which were one of the reasons 
I'm not using it.

Plus, as Adam said many times, the .di generation is pretty raw 
right now, so, there's a lot of handwork to maintain one of 
those, I believe that solving those items could be improved.


Plus, we could create an attribute specifically used for 
templates which are meant to only be instantiated once, such as 
`@noexport`, which would mean that in the .di output, it would 
not need to keep the template itself. This is useful for not 
exporting code that was only done for inline ctfe'd.


More information about the Digitalmars-d mailing list