On Wednesday, 19 July 2017 at 12:15:05 UTC, Mike Parker wrote:
> On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:
>> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:
>>> Try a newer compiler, this was fixed recently.
>>
>> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
>>
>> Sorry for wasting everyones' time if that's so, and thanks for the help.
>
> Ah, great!

Looks like it's https://wiki.dlang.org/DIP22 that changed this

On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:
> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:
>> Try a newer compiler, this was fixed recently.
>
> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
>
> Sorry for wasting everyones' time if that's so, and thanks for the help.

Just for the record, private is the analog of C's static. All private free and member functions are callable only from the module they are defined in. This is in contrast with C++, Java, C# where private members are visible only the class they are defined in.

On Wednesday, 19 July 2017 at 12:16:46 UTC, John Burton wrote:

>
> Looks like it's https://wiki.dlang.org/DIP22 that changed this

Specifically, it was fixed in DMD 2.071.0 released in April of last year:

http://dlang.org/changelog/2.071.0.html#dip22

On 2017-07-19 14:11, John Burton wrote:

> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
> 
> Sorry for wasting everyones' time if that's so, and thanks for the help.

I suspected something like this :). Nice to hear that you sorted it out.

-- 
/Jacob Carlborg

On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote:
> On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:
>> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:
>>> Try a newer compiler, this was fixed recently.
>>
>> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
>>
>> Sorry for wasting everyones' time if that's so, and thanks for the help.
> 
> Just for the record, private is the analog of C's static. All private free and member functions are callable only from the module they are defined in. This is in contrast with C++, Java, C# where private members are visible only the class they are defined in.

I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables.

You could still call a private function in a D module via the mangled name I believe.

-Steve

Note: not 100% sure of all this, but this is always the way I've looked at it.

On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer wrote:
> On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote:
>> On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:
>>> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:
>>>> Try a newer compiler, this was fixed recently.
>>>
>>> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
>>>
>>> Sorry for wasting everyones' time if that's so, and thanks for the help.
>> 
>> Just for the record, private is the analog of C's static. All private free and member functions are callable only from the module they are defined in. This is in contrast with C++, Java, C# where private members are visible only the class they are defined in.
>
> I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables.
>
> You could still call a private function in a D module via the mangled name I believe.
>
> -Steve
>
> Note: not 100% sure of all this, but this is always the way I've looked at it.

That's correct. We unfortunately can't do certain optimizations because of this (executable size related: removing unused or inlined only functions, ...).

The reason we can't make private functions object local are templates. A public template can access private functions, but the template instance may be emitted to another object. And as templates can't be checzked speculatively we don't even know if there's a template accessing a private function.

Dlls on Windows face a similar problem. Once we get the export templates proposed in earlier Dll discussions we can make non-exported, private functions object local.

On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer wrote:
> On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote:
>> On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:
>>> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:
>>>> Try a newer compiler, this was fixed recently.
>>>
>>> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
>>>
>>> Sorry for wasting everyones' time if that's so, and thanks for the help.
>> 
>> Just for the record, private is the analog of C's static. All private free and member functions are callable only from the module they are defined in. This is in contrast with C++, Java, C# where private members are visible only the class they are defined in.
>
> I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables.
>
> You could still call a private function in a D module via the mangled name I believe.
>
> -Steve
>
> Note: not 100% sure of all this, but this is always the way I've looked at it.

You're probably right about the current implementation, but I was talking about the intended semantics. I believe that with DIP45, only functions and global variables annotated with the export storage class would necessary have externally visible symbols.

Also, consider this enhancement request (which I think Walter and Andrei approve of) - https://issues.dlang.org/show_bug.cgi?id=13567 - which would be doable only if private functions don't have externally visible symbols.

See also: https://issues.dlang.org/show_bug.cgi?id=9893.

On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer wrote:
> I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables.

They generate hidden symbols. That's just how it implements private functions in C: you can't do anything else without mangling. You probably can't compile two C units into one object file if they have static functions with the same name - this would require mangling to make two symbols different.

Am Wed, 19 Jul 2017 17:25:18 +0000
schrieb Petar Kirov [ZombineDev] <petar.p.kirov@gmail.com>:


> >
> > Note: not 100% sure of all this, but this is always the way I've looked at it.
> 
> You're probably right about the current implementation, but I was talking about the intended semantics. I believe that with DIP45, only functions and global variables annotated with the export storage class would necessary have externally visible symbols.
> 

Yes, this DIP is the solution to have true C-like static functions. Non-exported private will then be equivalent to C static.

> Also, consider this enhancement request (which I think Walter and Andrei approve of) - https://issues.dlang.org/show_bug.cgi?id=13567 - which would be doable only if private functions don't have externally visible symbols.

Can you explain why _object-level visibility_ would matter in this case?

-- Johannes

Am Wed, 19 Jul 2017 17:37:48 +0000
schrieb Kagamin <spam@here.lot>:

> On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer wrote:
> > I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables.
> 
> They generate hidden symbols. That's just how it implements private functions in C: you can't do anything else without mangling.

This is not entirely correct. The symbols are local symbols in elf terminology, so local to an object file. Hidden symbols are local to an executable or shared library.

> You probably can't compile two C units into one object file if they have static functions with the same name - this would require mangling to make two symbols different.

1) C does have mangling for static variables:
void foo() {static int x;}
==> .local	x.1796

2)
Object file? No, but you cant compile two translation units into one
object file anyway or declare two functions with the same name in one
translation file.
For executables and libraries, ELF takes care of this. One major usecase
of static functions is not polluting the global namespace.

-------------------------------------------------------
static int foo(int a, int b)
{
    return a + b + 42;
}

int bar(int a, int b)
{
    return foo(a, b);
}
-------------------------------------------------------
nm =>
0000000000000017 T bar
0000000000000000 t foo

-------------------------------------------------------
static int foo(int a, int b)
{
    return -42;
}

int bar(int a, int b);

int main()
{
    return bar(1, 2);
}
-------------------------------------------------------
nm =>
                 U bar
0000000000000000 t foo
                 U _GLOBAL_OFFSET_TABLE_
0000000000000011 T main

nm a.out | grep foo =>
000000000000063a t foo
0000000000000670 t foo

Additionally, when compiling with optimizations both foos are gone: All calls are inlined, the functions are never referenced and therefore removed. This can reduce executable size a lot if you have many local helper functions, so D may benefit from this optimization as well.


-- Johannes