Feature request: "noexport" keyword

[Nick Sabalausky]

"Bekenn" <leaveme at alone.com> wrote in message 
news:ijrjh2$20sv$1 at digitalmars.com...
> On 2/19/2011 11:30 PM, Nick Sabalausky wrote:
>> "Bekenn"<leaveme at alone.com>  wrote in message
>> news:ijqffm$6lk$1 at digitalmars.com...
>> I'm not 100% certain, but I think this should already do what you want:
>>
>> export extern (Windows):
>> void func1();
>> int func2();
>>
>> public:
>> void func3();
>> void func4();
>>
>>
>>
>
>
> Hmm... I think you may be right.  I hadn't considered that, but it makes 
> sense.  I was thinking that the "export" attribute was independent of the 
> other protection attributes, which would introduce an asymmetry: private, 
> package, and public could each be overridden by supplying a different 
> protection attribute, but export couldn't be overridden. However, thinking 
> about it, a "private export" wouldn't make much sense (and "export" is 
> listed as a protection attribute, right along with the others), so I guess 
> they must all be mutually exclusive.
>
> I just tested this by trying to compile a module with the following line:
>
> public export void func();
>
> The compiler rejects it with the message "redundant protection attribute." 
> I think that pretty clearly settles this issue.

Yea. Actually I just happened to be reading the section about protection 
attributes in Andrei's "The D Programming Language" book just the other day, 
and the way it talked about them indicated they were all mutually-exclusive. 
Were it not for that, I probably would have made the same assumption as you. 
Not sure why, though, because as you say, "private/protected export" doesn't 
seem to make much sence.