"Nick Sabalausky" <a@a.a> wrote in message news:ijs2f1$5ri$1...@digitalmars.com... > "Bekenn" <leav...@alone.com> wrote in message > news:ijrjh2$20sv$1...@digitalmars.com... >> On 2/19/2011 11:30 PM, Nick Sabalausky wrote: >>> "Bekenn"<leav...@alone.com> wrote in message >>> news:ijqffm$6lk$1...@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.
