Feature request: "noexport" keyword

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:ijs2f1$5ri$1 at digitalmars.com...
> "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.
>

Keep in mind though, I have *no* idea how "extern(...)" fits in to all of 
this.