DIP22 : Private symbol visibility

[Jesse Phillips]

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());