On Wednesday, 16 May 2018 at 06:11:13 UTC, Tobias Müller wrote:
> KingJoffrey <KingJoffrey@KingJoffrey.com> wrote:
>> actually, private is default in Rust.
>> 
>> public is default in D.
>> 
>> also, in Rust, private is private within the module, *and* its descendants.
>> 
>> I don't believe that is the case in D (someone correct me if I'm wrong)
>
> The point is, that the module is the abstraction boundary.

Yeah, but "The unit of object encapsulation in D is the class."
 - page 175, The D Programming Language, 2010, Andrei Alexandrescu.

They cannot both be true. And this leaves room for confusion for new comers to D,
unless they all get to page 200 in time, where it says:

"In all contexts, private has the same power: it restricts symbol access to the current module (file). This behavior is unlike that in other languages, which limit access to private symbols to the current class only. ...  If class-level protection is needed, simply put the class in its own file."

Now something like that in the spec I mentioned (on the D website), would not do any harm to the spec, would it?

On Wednesday, 16 May 2018 at 06:17:51 UTC, Uknown wrote:
>
> `public` by default is again not a problem. Just apply `private` as necessary.

it's not a problem 'if' you 'remember' to use 'private'.

private 'within the module' is also not a problem, 'if' you 'remember' that, when using private to encapsulate your class.

Again, other mainstream languages have already learn the lesson here, as to why public might not be a great 'default'.

knowledge is useful, I get it. so are safe defaults.

> Also, if you want the rust style `private`, D offers `package`, which means private to the modules contained by a package.

Thanks for clarifying this.

On Wednesday, 16 May 2018 at 06:34:35 UTC, KingJoffrey wrote:
> On Wednesday, 16 May 2018 at 06:17:51 UTC, Uknown wrote:
>> Also, if you want the rust style `private`, D offers `package`, which means private to the modules contained by a package.
>
> Thanks for clarifying this.

I did not read the rust spec :p, but from the conversations above I believe rust private is not D package. Rust private is private in the module, package in D is all modules in a package. D would be:

module mod;
private: // put this at top of file and everything below it is not private


public void f () {} // explicitly request this one to be public

On Wednesday, 16 May 2018 at 07:53:36 UTC, aliak wrote:
> On Wednesday, 16 May 2018 at 06:34:35 UTC, KingJoffrey wrote:
>> On Wednesday, 16 May 2018 at 06:17:51 UTC, Uknown wrote:
>>> Also, if you want the rust style `private`, D offers `package`, which means private to the modules contained by a package.
>>
>> Thanks for clarifying this.
>
> I did not read the rust spec :p, but from the conversations above I believe rust private is not D package. Rust private is private in the module, package in D is all modules in a package. D would be:
>
> module mod;
> private: // put this at top of file and everything below it is not private
>
>
> public void f () {} // explicitly request this one to be public

Just checked the rust spec [0]. private in rust => accessible from that module and its descendants, which is what package in D is. private in D would be to that module only.

[0]: https://doc.rust-lang.org/beta/reference/visibility-and-privacy.html

On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis wrote:
> On Wednesday, May 16, 2018 02:39:22 KingJoffrey via Digitalmars-d wrote:
>> On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:
>> > ...
...
>
>> The best clarification I can find, regarding how D treat's private, is from this tiny little sentence (from which, I assume, the programmer is now meant to understand it's full implications):
>>
>> "Symbols with private visibility can only be accessed from within the same module"
>>
>> https://dlang.org/spec/attribute.html#visibility_attributes
>
> It specifies what private does quite accurately. If you want something that's trying to point out how you might misunderstand the spec or what problems you might run into, you'll need to read something like Ali's book. The spec is telling you how the language works, not trying to tell you how you might misunderstand it or what misakes you might make.
...
>
> - Jonathan M Davis

a pitfall-section about 'private' and 'protected' in https://dlang.org/spec/class.html wouldnt hurt. KingJoffrey is not the first one at all who discovered this corner case _afterwards_. I saw it in the forum.
Additionally I am curious about the "you must read a book"-statement, if KingJoffrey learned almost anything by reading the specification-documentation except for a few pitfalls.

On Wednesday, 16 May 2018 at 08:20:23 UTC, Uknown wrote:
> On Wednesday, 16 May 2018 at 07:53:36 UTC, aliak wrote:
>
> Just checked the rust spec [0]. private in rust => accessible from that module and its descendants, which is what package in D is. private in D would be to that module only.
>
> [0]: https://doc.rust-lang.org/beta/reference/visibility-and-privacy.html

Dont know if its been mentioned before but in Delphi / Object Pascal private is accessible to everything in the same module. Same as D.

On Wednesday, May 16, 2018 05:43:58 KingJoffrey via Digitalmars-d wrote:
> On Wednesday, 16 May 2018 at 04:25:40 UTC, Jonathan M Davis wrote:
> > I think that really what you want is something that's geared more towards teaching the language. The ways that the language spec needs to be improved really revolve around making it a proper spec, which means making it far more precise, not making it more amenable to folks reading it in order to learn the language. But unfortunately, what we have right now is kind of in the middle. It's not precise enough to really be a proper spec, and it's generally terse enough that it's harder to use it as a learning resource (though it usually has the necessary information in it).
> >
> > - Jonathan M Davis
>
> Also, having a C++ like spec, written by the elite, for the elite, and then everyone else has to wait until some kind person explains the spec, is really not a great model.
>
> It's equivalent to the elitist view of trickle down economics - which is not working in my country.

A C++-like spec is exactly what a language specification should be. It's intended for folks like compiler writers so that they know the exact rules of the language in excruciating detail so that every implementation can match in the ways that they need to match (as well as making it so that the compiler writer knows where they have leeway). D's spec is very poor in that regard, largely because writing specs is not one of Walter Bright's strengths (something that he has freely admitted on several occasions). However, Andrei has made it a priority to improve D's spec so that it is detailed in the way that the C++ spec is. So, we should see movement towards having a spec more like what C++ has.

Part of the problem with D's spec is that it's basically both trying to be a specification for the language and be a way to explain the language to the typical programmer, and those aren't really compatible goals. We really need to have anything intended to teach the language be separate from the spec, but historically, the main resource that we've had is the spec. Fortunately however, the number of books that we have about D has been increasing, and for many programmers, those are going to be better tools for learning the language.

- Jonathan M Davis

On Wednesday, 16 May 2018 at 10:24:02 UTC, Jonathan M Davis wrote:
> Part of the problem with D's spec is that it's basically both trying to be a specification for the language and be a way to explain the language to the typical programmer, and those aren't really compatible goals. We really need to have anything intended to teach the language be separate from the spec..

The specification (the one available above under 'Documentation', can be simply be 'annotated', and therefore serve more that just 'folks like compiler writers'.

Those who don't need the annotations, can just ignore the annotations.

I'm not talking 'tutorials' here, just some extra, helpful explanation.

The C# Programming Language, 4th Edition, by Anders Hejlsberg (et al) is still one of my favourite all time books (because of the mix of specification and expert annotations).

On Wednesday, 16 May 2018 at 02:05:29 UTC, KingJoffrey wrote:
> On Tuesday, 15 May 2018 at 15:19:33 UTC, Jesse Phillips wrote:
>> On Tuesday, 15 May 2018 at 10:19:58 UTC, KingJoffrey wrote:
>>> My own code in D had bugs, cause I didn't realise all my private parts were not just visible, but accessible by all the so called 'friends' around me. They could reach in a do whatever they want! Without my consent!
>>
>> You've peaked my interest, could you give some details on one or more of these bugs?
>
> It's simple.
>
> Write a non-member function, contained in the same module as a class, and accidently use a private class member instead of the public getter/setter defined by the interface of that class.
>
> It's human error, that will occur time and time again, but will *never* get picked up in D, except through a debugging session, because D does not consider this an error.
>
> How can it, if private is not really private?
>
> Now the burden is back on the programmer again.
>
> Be careful what you put into a module.

That isn't a bug. What is the software use case? How did this case differ because someone did this?

Global variables and singletons are also frowned on, but call it bad coding not a bug.

On Wednesday, 16 May 2018 at 13:09:22 UTC, Jesse Phillips wrote:
>
> Global variables and singletons are also frowned on, but call it bad coding not a bug.

Come on, really? that's just word play, much like the use of the 'private' declaration in a class (in D that is).

(also, this was not an enterprise application I was developing (D's not ready by a long shot, for the big time, in my opinion) - it was just some code I was playing with in a sandbox (i.e a module).