Feature request: "noexport" keyword

[Jonathan M Davis]

On Saturday 19 February 2011 23:19:39 Bekenn wrote:
> 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?

Just use braces with export. Problem solved.

I can see why noexport could be useful, but there are plenty of other attributes 
which don't have a negative (e.g. nothrow and pure). If we want to add something 
like noexport, we probably want a more generic way to do it than adding no 
export.

Of course, I _much_ prefer the way that Linux just exports all symbols, and you 
don't have have to specify which get exported and which don't (I _hate_ having 
to deal with that in Windows in C++ - _especially_ since I'm typically doing 
cross-platform stuff that then uses a macro, and I forget to use it, since it 
does nothing on Linux, and that's what I'm usually developing on). I hadn't even 
realized that D _had_ an export keyword. If anything, I'd argue that D should 
ditch it and just make _everything_ export and be done with it.

- Jonathan M Davis