On 12/22/2012 1:04 AM, Jonathan M Davis wrote:
> Walter has completely convinced me with regards to how bad an idea
> compiler warnings are.

Wow!

On 12/22/12 9:29 PM, Walter Bright wrote:
> On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
>> Pretty much every time that this issue comes up, people are surprised
>> by the
>> fact that private symbols aren't hidden and pretty much no one wants
>> them to
>> be in overload sets.
>
> This has been discussed before, and the same people wanted private
> functions removed from overload sets in classes.
>
> So why does this never come up in C++ if it's such a problem? Like I
> said, I've never seen this come up on peoples' lists of what they don't
> like about C++, and it isn't because they're shy about complaining about
> C++ :-)

The scope is very different. We're talking classes vs. entire modules and, by percolation of symbols, entire applications.

The comparison would be inappropriate, as would be deriving conclusions applicable to D from it.

Private inside a module must mean what the person on the street thinks. No visibility outside the module at all. There are no two ways about it.


Andrei

On Sunday, 23 December 2012 at 02:35:46 UTC, Walter Bright wrote:
> On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
>> I think this is a fallacious argument because it concludes that apples should be
>> peeled because oranges should.
>
> Given, in C++:
>
> struct S
> {
>   public:
>      void foo(int);
>   private:
>      void foo(float);
> }
>
> void bar()
> {
>     S s;
>     s.foo(1.0f);
> }
>
> This is an error in C++:
>
> foo.cpp:6: error: âvoid S::foo(float)â is private
>
> (I used g++ so nobody would complain this is a defect in dmc++.)
>
> Why does this never come up on peoples' complaints about C++? I spent some time googling it, and came up with nothing.
>
> I don't think it can be dismissed as fallacious unless the why's have a rationale.

I don't see how that example can be compared with the issue Jonathan is raising.

If I understood the issue correctly, the visibility of all module members are global in scope, and that's why two modules may have names that clash. What people want are private module members not to be visible outside of the module.

We're speaking about D rather than C++, but I can give you an example of how a somewhat analogous situation can cause serious problems in C++.

When using dlopen() with the RTLD_GLOBAL flag, it causes all symbols from the loaded library to become visible to subsequently loaded libraries. When there are symbol clashes, instead of an error, one of the symbols is used rather than the other, causing the application to behave in unexpected ways.

For dlopen() the default behavior is RTLD_LOCAL, which makes all symbols from loaded libs private to their respective libs. This is the default behavior to ensure predictable execution behaviors, and it's the same default behavior that modules should have.

--rt

On Sunday, 23 December 2012 at 04:43:27 UTC, Rob T wrote:
> For dlopen() the default behavior is RTLD_LOCAL, which makes all symbols from loaded libs private to their respective libs. This is the default behavior to ensure predictable execution behaviors, and it's the same default behavior that modules should have.
>
> --rt

I meant:

"it's the same default behavior that private module members should have.", ie, they should not be visible outside of the module.

On 12/23/2012 03:35 AM, Walter Bright wrote:
> On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
>> I think this is a fallacious argument because it concludes that apples
>> should be
>> peeled because oranges should.
>
> Given, in C++:
>
> struct S
> {
>    public:
>       void foo(int);
>    private:
>       void foo(float);
> }
>
> void bar()
> {
>      S s;
>      s.foo(1.0f);
> }
>
> This is an error in C++:
>
> foo.cpp:6: error: âvoid S::foo(float)â is private
>
> (I used g++ so nobody would complain this is a defect in dmc++.)
>

structs and classes are utterly irrelevant at this point of the discussion.

Are you aware what the problem Andrei was referring to is?

> Why does this never come up on peoples' complaints about C++? I spent
> some time googling it, and came up with nothing.
>

This is not the primary problem, because it can be avoided by not overloading public vs. private against each other.

This is the problem:

module a;
private void foo(){}

module b;
public void foo(){}

module c;
import a,b;
void main() {
    foo(); // error: conflict
}

The error message is misleading. There is no conflict. Nor is there a problem. The error is completely spurious.

> I don't think it can be dismissed as fallacious unless the why's have a
> rationale.
>

Modularity is achieved in rather ad-hoc ways in C++. Why do you think C++ is relevant?

On Sunday, December 23, 2012 05:56:07 Timon Gehr wrote:
> structs and classes are utterly irrelevant at this point of the discussion.

That's mostly true, but UFCS probably makes it so that structs and classes are in the same boat as free functions in modules are. Without UFCS, it's a relatively minor issue. But since C++ doesn't have UFCS, once again, this is an issue that D has that C++ doesn't, making the fact that people don't complain about this much in C++ pretty much irrelevant.

- Jonathan M Davis

Walter Bright wrote:
> On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
>> Pretty much every time that this issue comes up, people are surprised
>> by the
>> fact that private symbols aren't hidden and pretty much no one wants
>> them to
>> be in overload sets.
> 
> This has been discussed before, and the same people wanted private functions removed from overload sets in classes.
> 
> So why does this never come up in C++ if it's such a problem? Like I said, I've never seen this come up on peoples' lists of what they don't like about C++, and it isn't because they're shy about complaining about C++ :-)

	Because C++ *can* hide symbols from other modules with the
anonymous namespace. D has no equivalent.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Jonathan M. Davis wrote:
> A lint-like tool is free to point them out for you, and maybe an IDE could highlight them, but actually making the compiler consider unused variables to be either a warning or an error would be an incredibly bad idea for D - on top of the fact that it would be really annoying.

I find the notion of warnings with brazillions of compiler flags to be
outdated, anyways. I do want the possibility to obtain more information
from the compiler (in the lint-like fashion), but not in a way that spams
the console and I miss serious information.
So the nice thing to have here would be a standardized interface to the
compiler, or even compiler as a library, with direct data access to this
kind of information. An IDE could then process that, mark unused variables
and other possible errors in funky colors if desired, list them somewhere,
or even show it as an error info in the IDE if the user really wants that.
The user can then directly fade out warnings for code parts known to be
correct on IDE level.
Same thing could be done with custom scripts for the command line folks.

On Sunday, 23 December 2012 at 12:20:01 UTC, Tobias Pfaff wrote:
> So the nice thing to have here would be a standardized interface to the
> compiler, or even compiler as a library, with direct data access to this
> kind of information.

Yes the concept of what a complier is, how how it is implemented should be redefined. The current concept is monolithic, you cannot easily extend it (no one can, not even the compiler devs), or make use of it outside of an extremely narrow usage range. Restructuring the compiler into a much more flexible and extensible tool is something that should be dealt at a later point, but there is a much bigger problem that needs to be taken on concerning how the language specification is being managed. Without a clear language specification that is accessible to everyone (try downloading it), and without a defined process to manage it, no one really knows fully what the language is supposed to be doing, and that limits severely what people are able to do in many areas. There's also a huge amount of endless discussions that never seem to conclude, and when there is a conclusion often the conclusion is not implemented or even retained for future reference.

--rt

On Sunday, December 23, 2012 12:20:01 Tobias Pfaff wrote:
> So the nice thing to have here would be a standardized interface to the compiler, or even compiler as a library, with direct data access to this kind of information.

The plan is to have a lexer and parser for D in the standard library, which would greatly simplify creating tools that did this sort of thing. We'd probably already have the lexer portion (I was working on it earlier this year), but I got insanely busy in real life. I'm hoping to get back to it fairly soon here though.

- Jonathan M Davis