On Wednesday, 30 January 2013 at 09:29:17 UTC, Dicebot wrote:
Case 1 (binary level, C + D):
----- sample.d -----
module sample;
private int func() { return 42; }
----------
----- oops.c -----
#include <stdio.h>
extern int _D6sample4funcFZi();
void* _Dmodule_ref = 0;
void* _D15TypeInfo_Struct6__vtblZ = 0;
void _Dmain() { }
int main()
{
long value = _D6sample4funcFZi();
printf("%ld\n", value);
return 0;
}
----------
----- shell -----
$ dmd - c sample.d
$ gcc -c oops.c
$ gcc oops.o sample.o
./a.out
42
----------
Are we really supporting C calling D functions? If we change the
function to extern(C) the compiler should probably error if it
private.
Case 2 (pure D, language level):
----- sample.d -----
module sample;
private struct Hest
{
int a, b;
}
public alias Hidden UseMe;
----------
----- oops.d -----
import sample;
import std.stdio;
void main()
{
UseMe tmp;
tmp.a = 42;
}
----------
I think there has been complaint that alias makes symbols public.
Though it can be nice to make template instances have nicer names.
Also a similar example:
Hest makeMe() { ... }
-------oops.d------
import sample;
void main() {
Hest tmp = makeMe();
int mine = tmp.a;
}
So thumbs up here
Case 3 (consistency):
I do insist on keeping class and module protection attribute
consistent. Saying class privates are always accessible from
other modules via tupleof & friends and module privates may be
not is causing confusion for no real gain. Also it may break
code if we have any means to enumerate module symbols via
traits (do we? I don't know).
I'm not sure what you said here. I assume you mean this should
work:
class Holder {
private int stuff;
}
------ Other module----
write("file", myHolder.serialize());
