• Hipreme (31/31) Mar 13 Currently, my engine is using `export` for debug builds, while I
• Richard (Rikki) Andrew Cattermole (1/1) Mar 13 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1045.md#export-a...
• Johan (21/22) Mar 14 My intuition says that it'll be more broadly useful if attributes
• Hipreme (5/27) Mar 14 Seconded. I believe having those core language attributes

Hipreme <msnmancini hotmail.com> writes:

Currently, my engine is using `export` for debug builds, while I 
wanted to not `export` things for release build.

That happens because I structured the engine to load a game as a 
DLL when in development. But for releases, it gets all built 
together. The problem is that the symbols are still `export`ed. 
And exporting a symbol increases binary size needlessly and also 
(possibly) losing some optimization opportunities since that 
symbol is exposed.

```d

version(Standalone)
{
     extern(System):
}
else version(dll): export extern(System):


int[2] getWindowSize(){return [HipRenderer.width, 
HipRenderer.height];}

void setWindowSize(uint width, uint height)
{
     HipRenderer.setWindowSize(width, height);
     HipRenderer.setViewport(viewport);
     
camera.setSize(cast(int)viewport.worldWidth,cast(int)viewport.worldHeight);
}

```

This is basically what I'm needing. I know that asking for that 
may be a chaos. But it would be good to at least have something 
like `export(dll)` or something like that, so, at least I would 
be able to use `version` for identifying if I need that exported 
or not.

That would basically mean, if I'm specifying `-version=dll`, 
`export` would work, else, it won't matter.

"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1045.md#export-annotation

Johan <j j.nl> writes:

On Friday, 14 March 2025 at 02:46:08 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1045.md#export-annotation

My intuition says that it'll be more broadly useful if attributes 
can be combined and aliased.
Something like this:

```
version(X) {
   // some arbitrary list of attributes
   alias attribs = AliasSeq!(export, extern(C), 
ldc.attributes.weak);
} else {
   // some arbitrary list of attributes
   alias attribs = AliasSeq!(extern(D), ldc.attributes.hidden);
}

 attribs
void foo() {}
```

You can already do this for the LDC attributes (because they are 
implemented as magic types), but not for D core language 
attributes.

-Johan

Hipreme <msnmancini hotmail.com> writes:

On Friday, 14 March 2025 at 12:07:00 UTC, Johan wrote:
 On Friday, 14 March 2025 at 02:46:08 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:
 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1045.md#export-annotation

 My intuition says that it'll be more broadly useful if 
 attributes can be combined and aliased.
 Something like this:

 ```
 version(X) {
   // some arbitrary list of attributes
   alias attribs = AliasSeq!(export, extern(C), 
 ldc.attributes.weak);
 } else {
   // some arbitrary list of attributes
   alias attribs = AliasSeq!(extern(D), ldc.attributes.hidden);
 }

  attribs
 void foo() {}
 ```

 You can already do this for the LDC attributes (because they 
 are implemented as magic types), but not for D core language 
 attributes.

 -Johan

Seconded. I believe having those core language attributes 
transformed into magic types would definitely solve a long 
standing issue on the language and would make more C/C++ 
behaviors (such as `#define dllimport`) available in the language.