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