Feature request: "noexport" keyword
Bekenn
leaveme at alone.com
Sat Feb 19 23:19:39 PST 2011
The "export" keyword is a protection attribute, along with "private",
"package", "protected", and "public". This means that it can be used
with the same syntax as any of those other attributes; for instance, if
creating a D "header" for an existing Windows DLL file, you might do
something like this:
export extern (Windows):
void func1();
int func2();
...
This notation is convenient when dealing with a very large existing
library; it avoids pointless repetition, and there's no need to keep
track of a closing end brace (as there would be with the scoped version).
The problem here is that there is no way to cancel an export attribute.
Whereas the other protection attributes can be overridden either locally:
public:
void func1();
package int func2();
...or globally:
public:
void func1();
package:
int func2();
...or with a scoped declaration, there is no way to specify that a given
symbol should *not* be exported once the "export:" version is used, or
inside a scoped export section.
A "noexport" keyword would be useful in these situations, if for
instance you want to add very small convenience functions that are
intended to be inlined and are not actually exported members of the DLL:
export extern (Windows):
void func1();
int func2();
const(char)* func3(int arg1, int arg2, const(char)* arg3, float arg4,
int arg5, void* arg6);
noexport const(char)* simpleFunc3(arg3, arg5, arg6) { return func3(0,
0, arg3, 3.14, arg5, arg6);
void func4();
...
Currently, to get the same effect, you have to either declare
simpleFunc3 above the export: line, use a scoped export block, or put
simpleFunc3 in an entirely different file. None of these provide the
same level of convenience.
What do you guys think?
More information about the Digitalmars-d
mailing list