www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP22 : Private symbol visibility

reply "Dicebot" <m.strashun gmail.com> writes:
http://wiki.dlang.org/DIP22

There are two important issues with current protection attribute
design:

* Senseless name clashes between private and public symbols
* No way to specify internal linkage storage class

This DIP addresses both of them with two decoupled proposals:

* Change of private related name resolution rules
* Definition of static storage class for module-scope symbols.

___________________________________________

Quotes, data and link to previous discussion:
http://wiki.dlang.org/Access_specifiers_and_visibility

___________________________________________

I think this is the point where public discussion will do more
good than my own exploration of corner cases. Please destroy and
pay closest attention to compile-time reflection - I have a
feeling I have missed something there.
Jan 28 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:

 http://wiki.dlang.org/DIP22


Error on that page (for C++):

" public
Default one, "if you can see symbol - you can access it"

That is true only for structs. For classes, "private" is the 
default.

See also this:

http://stackoverflow.com/questions/1247745/default-visibility-of-c-class-struct-members
Jan 28 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 17:18:27 UTC, eles wrote:

 On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:

 http://wiki.dlang.org/DIP22


 Error on that page (for C++):

 " public
 Default one, "if you can see symbol - you can access it"

 That is true only for structs. For classes, "private" is the 
 default.

 See also this:

 http://stackoverflow.com/questions/1247745/default-visibility-of-c-class-struct-members


It was on http://wiki.dlang.org/Access_specifiers_and_visibility 
actually, I had global symbols in mind when was writing that. 
Fixed now.
Jan 28 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/28/2013 06:05 PM, Dicebot wrote:

 http://wiki.dlang.org/DIP22

 There are two important issues with current protection attribute
 design:

 * Senseless name clashes between private and public symbols
 * No way to specify internal linkage storage class

 This DIP addresses both of them with two decoupled proposals:

 * Change of private related name resolution rules
 * Definition of static storage class for module-scope symbols.

 ___________________________________________

 Quotes, data and link to previous discussion:
 http://wiki.dlang.org/Access_specifiers_and_visibility

 ___________________________________________

 I think this is the point where public discussion will do more
 good than my own exploration of corner cases. Please destroy and
 pay closest attention to compile-time reflection - I have a
 feeling I have missed something there.


Fixing private is enough.

Not a fan of the static thing at all. It is a great thing that the 
static attribute actually has a consistent meaning in D.

mixin template X(){
     static int x = 2;
}

class C{
     mixin X; // x is a public TLS variable
}

mixin X; // x is a public TLS variable.

No need to screw this up.
Jan 28 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 17:36:58 UTC, Timon Gehr wrote:


 Fixing private is enough.

 Not a fan of the static thing at all. It is a great thing that 
 the static attribute actually has a consistent meaning in D.

 mixin template X(){
     static int x = 2;
 }

 class C{
     mixin X; // x is a public TLS variable
 }

 mixin X; // x is a public TLS variable.

 No need to screw this up.


Good, that was exactly example I could not crystallize. I wanted 
to avoid introduction of new keyword, thus reused static. May be 
there is no such way around.

Anyway, I intentionally kept static and private parts decoupled 
so either of them can be approved alone.
Jan 28 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
 Fixing private is enough.

 ...

 No need to screw this up.


By the way, do you oppose exactly "static" keyword usage or 
ability to mark symbols for internal linkage at all? How about 
something like  internal?
Jan 29 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/29/2013 11:29 AM, Dicebot wrote:

 Fixing private is enough.

 ...

 No need to screw this up.


 By the way, do you oppose exactly "static" keyword usage> or ability to
 mark symbols for internal linkage at all? How about something like
  internal?


I only oppose changing the meaning of "static". I do not have any strong 
feelings about being able to mark symbols for internal linkage, but I do 
not see why it is necessary. Can't a compiler just mark all symbols for 
internal linkage that can be marked such given the constraints you would 
impose on  internal marked symbols?
Jan 29 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 29 January 2013 at 16:44:56 UTC, Timon Gehr wrote:

 On 01/29/2013 11:29 AM, Dicebot wrote:

 Fixing private is enough.

 ...

 No need to screw this up.


 By the way, do you oppose exactly "static" keyword usage> or 
 ability to
 mark symbols for internal linkage at all? How about something 
 like
  internal?


 I only oppose changing the meaning of "static". I do not have 
 any strong feelings about being able to mark symbols for 
 internal linkage, but I do not see why it is necessary. Can't a 
 compiler just mark all symbols for internal linkage that can be 
 marked such given the constraints you would impose on  internal 
 marked symbols?


As far as I can see, it is rather problematic. When compiling 
module compiler may never know what will be referenced from other 
object files during link time. Even private symbols that do not 
leak can't be removed away that simple - we really want to 
preserve ability to access private members via tupleof and/or 
traits for power libraries. And it is nice to have compiler 
support to verify symbols does not leak ( == you can 
change/remove it any time with 100% guarantees to break no other 
module ) as an additional cherry on top.
Jan 29 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 29 January 2013 at 16:44:56 UTC, Timon Gehr wrote:

 On 01/29/2013 11:29 AM, Dicebot wrote:

 Fixing private is enough.

 ...

 No need to screw this up.


 By the way, do you oppose exactly "static" keyword usage> or 
 ability to
 mark symbols for internal linkage at all? How about something 
 like
  internal?


 I only oppose changing the meaning of "static". I do not have 
 any strong feelings about being able to mark symbols for 
 internal linkage, but I do not see why it is necessary. Can't a 
 compiler just mark all symbols for internal linkage that can be 
 marked such given the constraints you would impose on  internal 
 marked symbols?


I have to support that.

static have already quite a lot of different meaning in D, and 
adding yet a new one probably not a good idea. Especially when 
module level declaration are supposed to be static by default, so 
now they can be static static, which is clearly a bad idea.

Is the usage of export have been considered here ? private 
declaration are static/private, unless defined export ? Does that 
work ?
Jan 29 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 30 January 2013 at 03:54:53 UTC, deadalnix wrote:

 I have to support that.

 static have already quite a lot of different meaning in D, and 
 adding yet a new one probably not a good idea. Especially when 
 module level declaration are supposed to be static by default, 
 so now they can be static static, which is clearly a bad idea.

 Is the usage of export have been considered here ? private 
 declaration are static/private, unless defined export ? Does 
 that work ?


Yes, Timons example has convinced me with no doubts. I never 
wanted to use static that much to be honest, just avoid 
introduction of new attribute.

Regarding private as internal by default - please look at those 
examples: 
http://forum.dlang.org/post/irrbdrxordjawkryvrub forum.dlang.org 
If we force internal linkage of private unless marked as export, 
it will break code like in case 2 or require some weird mangling 
hacks like in C/C++. I do not feel that it is justified, as those 
2 concepts are rather different anyway. But it may be an option, 
need to evaluate all consequences though.
Jan 30 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-28 18:05, Dicebot wrote:

 http://wiki.dlang.org/DIP22

 There are two important issues with current protection attribute
 design:

 * Senseless name clashes between private and public symbols
 * No way to specify internal linkage storage class

 This DIP addresses both of them with two decoupled proposals:

 * Change of private related name resolution rules
 * Definition of static storage class for module-scope symbols.

 ___________________________________________

 Quotes, data and link to previous discussion:
 http://wiki.dlang.org/Access_specifiers_and_visibility

 ___________________________________________

 I think this is the point where public discussion will do more
 good than my own exploration of corner cases. Please destroy and
 pay closest attention to compile-time reflection - I have a
 feeling I have missed something there.


I think it looks good. What's not mentioned is ".tupleof", see:

http://forum.dlang.org/thread/llizpsrachdtqtshppud forum.dlang.org?page=2#post-ke6lv8:242nn8:241:40digitalmars.com

-- 
/Jacob Carlborg
Jan 28 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:

 http://wiki.dlang.org/DIP22


I think your going to need to give some evidence to the problems 
with the current behavior.

"dlang.org states that "Private module members are equivalent to 
static declarations in C programs." but this is wrong, they have 
external linkage:"

And this results in people writing code that ...? Is there an 
example where you can break code in another module by changing 
something marked as private?

"Name clash between public and private symbols has also been 
stated as unneeded and useless feature"

I'd be for this change, I don't know why it is currently that way 
though.

"There is currently no way in D to mark symbols for internal 
linkage"

What would that give us?

"Compiler errors upon access to private symbol are changed from 
"%s is not accessible" to "undefined identifier %s""

That will just be confusing. You put the name of that symbol 
because you saw it, being told it is undefined is going to make 
you think the compiler is broken.
Jan 29 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
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
----------

This is valid code now and will break. Internal linkage is a 
binary-level encapsulation tool, contrary to language-level 
private. Not that when compiling sample.d dmd can't know if 
oops.c will actually link to func and make decision about 
internal linkage. Saying this is invalid code may severely limit 
language interconnection possibilities and something like 
injecting druntime.

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;
}
----------

Now suddenly changing Test definition may break code in oops.d 
and we need first to make sure Test is not referenced in public 
aliases or as function parameter or as public type member field 
etc. Again, this code itself is not only valid but quite 
idiomatic. Internal linkage provides strong guarantees that any 
change to symbol will affect only its module, with no special 
cases.

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).
Jan 30 2013
parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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());
Jan 31 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 30 January 2013 at 05:29:14 UTC, Jesse Phillips 
wrote:

 And this results in people writing code that ...? Is there an 
 example where you can break code in another module by changing 
 something marked as private?


Examples separated:
http://forum.dlang.org/post/irrbdrxordjawkryvrub forum.dlang.org


 "There is currently no way in D to mark symbols for internal 
 linkage"

 What would that give us?


Strong 100% guarantees changes to the symbol won't break anything 
but its module. Strong 100% guarantees to compiler that he can 
optimize away/change all internal code when doing separate 
compilation.


 "Compiler errors upon access to private symbol are changed from 
 "%s is not accessible" to "undefined identifier %s""

 That will just be confusing. You put the name of that symbol 
 because you saw it, being told it is undefined is going to make 
 you think the compiler is broken.


That was the most uneasy part of proposal. I have been thinking 
for few hours about it, considering different options. In the 
end, I have decided that it is only confusing to one coming from 
C++ lax approach and for clean mind it should make perfect sense 
that private symbol is indistinguishable from non-existing one in 
regular user code - that is the point of encapsulation how I get 
it.

Also in case of denied access most likely you have put that 
symbol because of typo, not because you know it (why would you 
intentionally try to use symbol you already know is private?). 
And it exposes internal module details by an accident.

I am very open for more arguments though, it is a somewhat tricky 
change.
Jan 30 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 30 January 2013 at 09:42:01 UTC, Dicebot wrote:

 On Wednesday, 30 January 2013 at 05:29:14 UTC, Jesse Phillips 
 wrote:

 And this results in people writing code that ...? Is there an 
 example where you can break code in another module by changing 
 something marked as private?


 Examples separated:
 http://forum.dlang.org/post/irrbdrxordjawkryvrub forum.dlang.org


I understand the risk of breakage. But . . .

Is this code supposed to work in the first place ? I mean, the 
private function is not marked export, the language make no 
guarantee it will be accessible from C.

Additionally, does it make sense to prevent D from calling some 
piece of code, but still allow some external C code to do it ?

I think it is invalid code in the first place, and just happen to 
work right now.

case 2 is more tricky, but export isn't involved here.
Jan 30 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-30 10:57, deadalnix wrote:


 I understand the risk of breakage. But . . .


Not worth the breakage.


 Is this code supposed to work in the first place ? I mean, the private
 function is not marked export, the language make no guarantee it will be
 accessible from C.

 Additionally, does it make sense to prevent D from calling some piece of
 code, but still allow some external C code to do it ?

 I think it is invalid code in the first place, and just happen to work
 right now.

 case 2 is more tricky, but export isn't involved here.


It's not just accessing from C code. Due to D supporting separate 
compilation you can have the implementation of a private method in a 
separate object file.

-- 
/Jacob Carlborg
Jan 30 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 30 January 2013 at 12:02:46 UTC, Jacob Carlborg 
wrote:

 It's not just accessing from C code. Due to D supporting 
 separate compilation you can have the implementation of a 
 private method in a separate object file.


The code is in C in the example. But if you replace the C code by 
another D module, the exact same reasoning holds.

What point are you trying to make by raising that ? It seems 
completely irrelevant to me. Or I didn't inferred the part of the 
reasoning that was implied in your post. Please make it explicit.
Jan 30 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-30 17:26, deadalnix wrote:


 The code is in C in the example. But if you replace the C code by
 another D module, the exact same reasoning holds.

 What point are you trying to make by raising that ? It seems completely
 irrelevant to me. Or I didn't inferred the part of the reasoning that
 was implied in your post. Please make it explicit.


If you have a public and a private function in the same module, it's 
possible to implement the two functions in two separate object files. 
The private function must then be available in the object file to link 
the program properly.

-- 
/Jacob Carlborg
Jan 30 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 30 January 2013 at 20:22:11 UTC, Jacob Carlborg 
wrote:

 If you have a public and a private function in the same module, 
 it's possible to implement the two functions in two separate 
 object files. The private function must then be available in 
 the object file to link the program properly.


Ugh, how can you split module into two source/object files? Naive 
approach will result in linker error due to multiple definition 
of ModuleInfo. I did not know it was possible, would have been 
really cool to have.
Jan 31 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-31 11:11, Dicebot wrote:


 Ugh, how can you split module into two source/object files? Naive
 approach will result in linker error due to multiple definition of
 ModuleInfo. I did not know it was possible, would have been really cool
 to have.


I'm not 100% sure if it's possible, but it's theoretically possible.

-- 
/Jacob Carlborg
Jan 31 2013
parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 31 January 2013 at 12:10:29 UTC, Jacob Carlborg 
wrote:

 On 2013-01-31 11:11, Dicebot wrote:


 Ugh, how can you split module into two source/object files? 
 Naive
 approach will result in linker error due to multiple 
 definition of
 ModuleInfo. I did not know it was possible, would have been 
 really cool
 to have.


 I'm not 100% sure if it's possible, but it's theoretically 
 possible.


How _exactly_ is it even theoretically possible in D? Sciolism 
rarely helps when discussing technical issues.

The hard part regarding separate compilation in D is to determine 
the object file(s) a template instance is emitted to, and the 
visibility of the symbol. But whether a private symbol is 
»leaked« into the public API of a module or not can always be 
determined by just examining the module in question. So, it 
should be doable, even though the current DMD implementation has 
bugs in this regard.

David
Feb 02 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 30 January 2013 at 20:22:11 UTC, Jacob Carlborg 
wrote:

 On 2013-01-30 17:26, deadalnix wrote:


 The code is in C in the example. But if you replace the C code 
 by
 another D module, the exact same reasoning holds.

 What point are you trying to make by raising that ? It seems 
 completely
 irrelevant to me. Or I didn't inferred the part of the 
 reasoning that
 was implied in your post. Please make it explicit.


 If you have a public and a private function in the same module, 
 it's possible to implement the two functions in two separate 
 object files. The private function must then be available in 
 the object file to link the program properly.


This is why most languages with modules do have their own linker, 
instead of relying on the 70's constraints of C linkers.

--
Paulo
Jan 31 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/30/2013 10:42 AM, Dicebot wrote:

 ...
 That was the most uneasy part of proposal. I have been thinking for few
 hours about it, considering different options. In the end, I have
 decided that it is only confusing to one coming from C++ lax approach
 and for clean mind it should make perfect sense that private symbol is
 indistinguishable from non-existing one in regular user code - that is
 the point of encapsulation how I get it.
 ...


As long as compile-time reflection cannot get hold of the error message, 
the more helpful diagnostic does not do any harm. (After all, the 
programmer might still be aware of the existence of the member, but 
missing that it is not accessible (yet) from the module he/she is 
currently working on.)
Jan 30 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 30 January 2013 at 11:39:26 UTC, Timon Gehr wrote:

 On 01/30/2013 10:42 AM, Dicebot wrote:

 ...
 That was the most uneasy part of proposal. I have been 
 thinking for few
 hours about it, considering different options. In the end, I 
 have
 decided that it is only confusing to one coming from C++ lax 
 approach
 and for clean mind it should make perfect sense that private 
 symbol is
 indistinguishable from non-existing one in regular user code - 
 that is
 the point of encapsulation how I get it.
 ...


 As long as compile-time reflection cannot get hold of the error 
 message, the more helpful diagnostic does not do any harm. 
 (After all, the programmer might still be aware of the 
 existence of the member, but missing that it is not accessible 
 (yet) from the module he/she is currently working on.)


I am arguing exactly that it is more helpful as it somewhat 
breaks encapsulation. I really believe it is good to not give out 
information that was no supposed to be shown. What do you think 
about changing both undefined and denied access messages to one 
"symbol is undefined or inaccessible" then?
Feb 01 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
01-Feb-2013 13:34, Dicebot пишет:

 On Wednesday, 30 January 2013 at 11:39:26 UTC, Timon Gehr wrote:

 On 01/30/2013 10:42 AM, Dicebot wrote:

 ...
 That was the most uneasy part of proposal. I have been thinking for few
 hours about it, considering different options. In the end, I have
 decided that it is only confusing to one coming from C++ lax approach
 and for clean mind it should make perfect sense that private symbol is
 indistinguishable from non-existing one in regular user code - that is
 the point of encapsulation how I get it.
 ...


 As long as compile-time reflection cannot get hold of the error
 message, the more helpful diagnostic does not do any harm. (After all,
 the programmer might still be aware of the existence of the member,
 but missing that it is not accessible (yet) from the module he/she is
 currently working on.)


 I am arguing exactly that it is more helpful as it somewhat breaks
 encapsulation. I really believe it is good to not give out information
 that was no supposed to be shown. What do you think about changing both
 undefined and denied access messages to one "symbol is undefined or
 inaccessible" then?


just tell what it is: not visible, period!

And BTW good dip, the first part.

The second about internal (C's static) is up for more work.

-- 
Dmitry Olshansky
Feb 01 2013
prev sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Wednesday, 30 January 2013 at 09:42:01 UTC, Dicebot wrote:

 On Wednesday, 30 January 2013 at 05:29:14 UTC, Jesse Phillips 
 wrote:

 And this results in people writing code that ...? Is there an 
 example where you can break code in another module by changing 
 something marked as private?


 Examples separated:
 http://forum.dlang.org/post/irrbdrxordjawkryvrub forum.dlang.org


I meant more that these questions should be answered the DIP page.


 "Compiler errors upon access to private symbol are changed 
 from "%s is not accessible" to "undefined identifier %s""

 That will just be confusing. You put the name of that symbol 
 because you saw it, being told it is undefined is going to 
 make you think the compiler is broken.





 Also in case of denied access most likely you have put that 
 symbol because of typo, not because you know it (why would you 
 intentionally try to use symbol you already know is private?). 
 And it exposes internal module details by an accident.


My assumption is that I don't know why you put that symbol there. 
Did you know it was private? Did you intent to make it public? 
Did you forget what you were doing and entered a random word, 
were told it was undefined, looked up the source and complained 
that you could see it?

How you found that the symbol is defined isn't a concern to me, 
it is the fact that you can verify and be confused that the 
compiler doesn't see it.
Jan 31 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 31 January 2013 at 20:43:14 UTC, Jesse Phillips 
wrote:

 I meant more that these questions should be answered the DIP 
 page.


Sure, I just want to gather more opinions before doing version 2 
of DIP. Most likely will gather all together this weekend.


 My assumption is that I don't know why you put that symbol 
 there. Did you know it was private? Did you intent to make it 
 public? Did you forget what you were doing and entered a random 
 word, were told it was undefined, looked up the source and 
 complained that you could see it?

 How you found that the symbol is defined isn't a concern to me, 
 it is the fact that you can verify and be confused that the 
 compiler doesn't see it.


Sorry, did not understand this part. Can you give a more code-ish 
example?
Feb 01 2013
next sibling parent "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
On Friday, 1 February 2013 at 09:36:19 UTC, Dicebot wrote:

 Sorry, did not understand this part. Can you give a more 
 code-ish example?


Sorry I can't. If you see code where function is defined, and the 
compiler complains it is not defined, it can lead to checking 
imports and supplied files instead of the cause, "not accessible."
Feb 01 2013
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 1 February 2013 at 09:36:19 UTC, Dicebot wrote:

 On Thursday, 31 January 2013 at 20:43:14 UTC, Jesse Phillips 
 wrote:

 I meant more that these questions should be answered the DIP 
 page.


 Sure, I just want to gather more opinions before doing version 
 2 of DIP. Most likely will gather all together this weekend.


I think at this point it is amply clear that the introduction of 
a "static"/"internal" keyword is much more controversial than the 
change to "private".

Thus, I'd recommend splitting up the DIP, so we can make progress 
on the "private" issue ASAP.

David
Feb 02 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 2 February 2013 at 13:27:46 UTC, David Nadlinger 
wrote:

 On Friday, 1 February 2013 at 09:36:19 UTC, Dicebot wrote:

 On Thursday, 31 January 2013 at 20:43:14 UTC, Jesse Phillips 
 wrote:

 I meant more that these questions should be answered the DIP 
 page.


 Sure, I just want to gather more opinions before doing version 
 2 of DIP. Most likely will gather all together this weekend.


 I think at this point it is amply clear that the introduction 
 of a "static"/"internal" keyword is much more controversial 
 than the change to "private".

 Thus, I'd recommend splitting up the DIP, so we can make 
 progress on the "private" issue ASAP.

 David


Agree, that was my conclusion, too.
Feb 02 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 28, 2013 18:05:37 Dicebot wrote:

 http://wiki.dlang.org/DIP22
 
 There are two important issues with current protection attribute
 design:
 
 * Senseless name clashes between private and public symbols
 * No way to specify internal linkage storage class
 
 This DIP addresses both of them with two decoupled proposals:
 
 * Change of private related name resolution rules
 * Definition of static storage class for module-scope symbols.


I see no point to the internal linkage stuff. What we need is for inaccessible 
symbols to not be put in overload sets. I'm not sure that it really needs to 
be any more complicated than that.

- Jonathan M Davis
Jan 31 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 31 January 2013 at 14:50:05 UTC, Jonathan M Davis 
wrote:

 I see no point to the internal linkage stuff. What we need is 
 for inaccessible
 symbols to not be put in overload sets. I'm not sure that it 
 really needs to
 be any more complicated than that.

 - Jonathan M Davis


I predicted there will be some tension about internal linkage 
stuff and mostly decoupled it from private stuff so that it can 
be easily separated into another DIP and implemented in case 
other part is rejected.

Still, no need for internal linkage is felt because D projects 
are very small nowadays and does not involve complex separate 
compilation systems and\or large teams of programmers working on 
a single project. What internal linkage gives you is hard 100% 
guarantee (verified by the compiler) that this piece of code may 
be changed as you wish and it won't affect anything but this 
module. Private can't give such guarantees without code breakage. 
It is a widely used idiom in C/C++ that D currently has no 
replacement.
Feb 01 2013
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Dicebot, el  1 de February a las 10:42 me escribiste:

 Still, no need for internal linkage is felt because D projects are
 very small nowadays and does not involve complex separate
 compilation systems and\or large teams of programmers working on a
 single project. What internal linkage gives you is hard 100%
 guarantee (verified by the compiler) that this piece of code may be
 changed as you wish and it won't affect anything but this module.
 Private can't give such guarantees without code breakage. It is a
 widely used idiom in C/C++ that D currently has no replacement.


Unfortunately D is different in this regard than C/C++ (yes, I said
unfortunately :P). Separate compilation in D is not that useful, as
interfaces are not clearly defined (at a file level). When you import
something, you are importing the implementation, not only the interface.
Is really hard to decouple both in D. I tried to play around with
separate (and incremental) compilation in D without much luck. And
I wonder if it ever will make any sense to compile separately instead of
all in one go.

Because of this, even when I agree about the goodness of "static
linkage" (as in C/C++), I don't see real value in this proposal for D.

PS: Yes, I know there are the .di files, but even trying to use that
    makes thing extremely hard, because you need to parse the whole file
    to generate it and the difference between parsing and compiling is
    not that much. And then, as in C++, you have templates.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
UNA ARTISTA HACE JABONES CON SU PROPIA GRASA LUEGO DE UNA LIPOSUCCION
	-- Crónica TV
Feb 01 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 1 February 2013 at 15:08:00 UTC, Leandro Lucarella 
wrote:

 Dicebot, el  1 de February a las 10:42 me escribiste:

 Still, no need for internal linkage is felt because D projects 
 are
 very small nowadays and does not involve complex separate
 compilation systems and\or large teams of programmers working 
 on a
 single project. What internal linkage gives you is hard 100%
 guarantee (verified by the compiler) that this piece of code 
 may be
 changed as you wish and it won't affect anything but this 
 module.
 Private can't give such guarantees without code breakage. It 
 is a
 widely used idiom in C/C++ that D currently has no replacement.


 Unfortunately D is different in this regard than C/C++ (yes, I 
 said
 unfortunately :P). Separate compilation in D is not that 
 useful, as
 interfaces are not clearly defined (at a file level). When you 
 import
 something, you are importing the implementation, not only the 
 interface.
 Is really hard to decouple both in D. I tried to play around 
 with
 separate (and incremental) compilation in D without much luck. 
 And
 I wonder if it ever will make any sense to compile separately 
 instead of
 all in one go.

 Because of this, even when I agree about the goodness of "static
 linkage" (as in C/C++), I don't see real value in this proposal 
 for D.

 PS: Yes, I know there are the .di files, but even trying to use 
 that
     makes thing extremely hard, because you need to parse the 
 whole file
     to generate it and the difference between parsing and 
 compiling is
     not that much. And then, as in C++, you have templates.


There are other languages with modules that also have generics,
although not as powerful as D's templates, surely they could be 
used as inspiration for how they are storing information on the 
compiled modules.

--
Paulo
Feb 01 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
What is wrong about *.di in this regard? Have just checked:

--- main.d ---
import test;

void main()
{
     import std.stdio;
     writeln(func());
}
------

--- test.di ---
module test;
int func();
------

--- test_impl.d ---
module test;

int func()
{
     return private_func();
}

private int private_func()
{
     return 42;
}
------

--- shell ---
$ dmd -c main.d
$ dmd -c test_impl.d
$ dmd -ofa.out main.o test_impl.o
$ ./a.out
42
-------

Am I missing something? Seems legit and pretty close to C++ model 
to me. You trade CTFE capabilities for more explicit interface.
Feb 01 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-01 16:08, Leandro Lucarella wrote:


 PS: Yes, I know there are the .di files, but even trying to use that
      makes thing extremely hard, because you need to parse the whole file
      to generate it and the difference between parsing and compiling is
      not that much. And then, as in C++, you have templates.


In C and C++ you don't have anything to generate them, you need to write 
them manually. You can do that same with D.

-- 
/Jacob Carlborg
Feb 01 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 1 February 2013 at 15:08:00 UTC, Leandro Lucarella 
wrote:

 I wonder if it ever will make any sense to compile separately 
 instead of
 all in one go.


My current project uses 2.5Gb of memory to compile. It take quite 
a long time as well. The project isn't that big (between 20000 
and 25000 LOC I'd say).

Due to dmd bugs, I cannot compile it separately. I really wish I 
could.
Feb 02 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 31 January 2013 at 14:50:05 UTC, Jonathan M Davis 
wrote:

 On Monday, January 28, 2013 18:05:37 Dicebot wrote:

 http://wiki.dlang.org/DIP22
 
 There are two important issues with current protection 
 attribute
 design:
 
 * Senseless name clashes between private and public symbols
 * No way to specify internal linkage storage class
 
 This DIP addresses both of them with two decoupled proposals:
 
 * Change of private related name resolution rules
 * Definition of static storage class for module-scope symbols.


 I see no point to the internal linkage stuff. What we need is 
 for inaccessible
 symbols to not be put in overload sets. I'm not sure that it 
 really needs to
 be any more complicated than that.


exported symbol cannot be optimized as much, as the compiler 
isn't aware of all calls. GCC people made some measurement about 
that and it ends up being significant.
Feb 02 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
OK, I have finally got to it and separated proposal into 
http://wiki.dlang.org/DIP22 (private) and 
http://wiki.dlang.org/DIP22.1 (internal linkage). "Private" 
proposal is updated according to this discussion. "Internal 
linkage" proposal is only separated, with no real changes, 
because I am not sure how it is best to address them now.

Also I am going to be very busy for 2 months or so and if someone 
wants to volunteer to take this over and push into approval in 
any shape - I would have been very grateful.
Feb 04 2013