On windows I was able to compile the following using both dmd.2.075.1 and dmd.2.076.1

From what I understand, you shouldn't be able to access private fields/methods like this...am I missing something?  I find it hard to believe that a bug of this magnitudue could have been introduced and not been noticed for so long. Does this compile on other people's systems as well?

import std.stdio;
struct SomeStruct
{
    private int privateValue;
    private void privateFunction()
    {
    }
}
class SomeClass
{
    private int privateValue;
    private void privateFunction()
    {
    }
}
void main()
{
    auto someStruct = SomeStruct(42);
    writefln("someStruct.privateValue = %s", someStruct.privateValue);
    someStruct.privateFunction();

    auto someStructRef = new SomeStruct(42);
    writefln("someStructRef.privateValue = %s", someStructRef.privateValue);
    someStruct.privateFunction();

    auto someClass = new SomeClass();
    writefln("someClass.privateValue = %s", someClass.privateValue);
    someClass.privateFunction();
}

On 10/10/17 3:20 PM, Jonathan Marler wrote:
> On windows I was able to compile the following using both dmd.2.075.1 and dmd.2.076.1
> 
>  From what I understand, you shouldn't be able to access private fields/methods like this...am I missing something?

Before I even read your code, I was pretty sure the error :)

private is module-based, not type based. Put your structs in a different module, and private will work.

-Steve

https://wiki.dlang.org/Access_specifiers_and_visibility#private

>Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class.

You can access private attributes anywhere in the same module.

Hah! Beat you by 10 seconds :)

-Steve

On Tuesday, 10 October 2017 at 19:33:30 UTC, Steven Schveighoffer wrote:
> On 10/10/17 3:20 PM, Jonathan Marler wrote:
>> On windows I was able to compile the following using both dmd.2.075.1 and dmd.2.076.1
>> 
>>  From what I understand, you shouldn't be able to access private fields/methods like this...am I missing something?
>
> Before I even read your code, I was pretty sure the error :)
>
> private is module-based, not type based. Put your structs in a different module, and private will work.
>
> -Steve

Wow I can't believe I've gone this long not realizing that.  I'm surprised there's not a way to make fields private to their own struct/class.

On Tuesday, October 10, 2017 19:50:49 Jonathan Marler via Digitalmars-d wrote:
> On Tuesday, 10 October 2017 at 19:33:30 UTC, Steven Schveighoffer
>
> wrote:
> > On 10/10/17 3:20 PM, Jonathan Marler wrote:
> >> On windows I was able to compile the following using both dmd.2.075.1 and dmd.2.076.1
> >>
> >>  From what I understand, you shouldn't be able to access
> >>
> >> private fields/methods like this...am I missing something?
> >
> > Before I even read your code, I was pretty sure the error :)
> >
> > private is module-based, not type based. Put your structs in a different module, and private will work.
> >
> > -Steve
>
> Wow I can't believe I've gone this long not realizing that.  I'm surprised there's not a way to make fields private to their own struct/class.

There is - by putting them in a separate module. It was done this way to avoid the extra complication of friend functions that you get in C++, and the theory is that you're in control of everything that's in your own module, so you should be able to deal with not having stuff access stuff in the same module when it shouldn't. And if you want nothing outside the type to have access, just stick the type in its own module.

- Jonathan M Davis

On Tuesday, October 10, 2017 15:33:30 Steven Schveighoffer via Digitalmars-d wrote:
> On 10/10/17 3:20 PM, Jonathan Marler wrote:
> > On windows I was able to compile the following using both dmd.2.075.1 and dmd.2.076.1
> >
> >  From what I understand, you shouldn't be able to access private
> >
> > fields/methods like this...am I missing something?
>
> Before I even read your code, I was pretty sure the error :)

LOL. Same here. It seems like almost everyone makes this mistake unless they caught the information first by doing something like reading the spec carefully or reading TDPL. And if you always treat your types as if nothing else can access their private members and don't need the equivalent of a C++ friend function, odds are, that you'll never notice...

- Jonathan M Davis

On 10/10/17 4:02 PM, Jonathan M Davis wrote:
> On Tuesday, October 10, 2017 15:33:30 Steven Schveighoffer via Digitalmars-d
> wrote:
>> On 10/10/17 3:20 PM, Jonathan Marler wrote:
>>> On windows I was able to compile the following using both dmd.2.075.1
>>> and dmd.2.076.1
>>>
>>>   From what I understand, you shouldn't be able to access private
>>>
>>> fields/methods like this...am I missing something?
>>
>> Before I even read your code, I was pretty sure the error :)
> 
> LOL. Same here. It seems like almost everyone makes this mistake unless they
> caught the information first by doing something like reading the spec
> carefully or reading TDPL. And if you always treat your types as if nothing
> else can access their private members and don't need the equivalent of a C++
> friend function, odds are, that you'll never notice...

Yeah, if you look back far enough in the forums, I'm pretty sure I posted a message similar to Mr. Marler's about this shocking revelation :)

-Steve

On Tuesday, 10 October 2017 at 19:59:05 UTC, Jonathan M Davis wrote:
>
> There is - by putting them in a separate module. It was done this way to avoid the extra complication of friend functions that you get in C++, and the theory is that you're in control of everything that's in your own module, [snip]

I hadn't realized this was the reason for it. Makes sense.

On Tuesday, 10 October 2017 at 20:02:32 UTC, Jonathan M Davis wrote:
> On Tuesday, October 10, 2017 15:33:30 Steven Schveighoffer via Digitalmars-d wrote:
>> On 10/10/17 3:20 PM, Jonathan Marler wrote:
>> > On windows I was able to compile the following using both dmd.2.075.1 and dmd.2.076.1
>> >
>> >  From what I understand, you shouldn't be able to access private
>> >
>> > fields/methods like this...am I missing something?
>>
>> Before I even read your code, I was pretty sure the error :)
>
> LOL. Same here. It seems like almost everyone makes this mistake unless they caught the information first by doing something like reading the spec carefully or reading TDPL. And if you always treat your types as if nothing else can access their private members and don't need the equivalent of a C++ friend function, odds are, that you'll never notice...
>
> - Jonathan M Davis

FWIW this confusion found it's way into Phobos as the unittest was in the same module:

https://dlang.org/phobos/std_traits.html#getSymbolsByUDA

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