I'd like to add that I have programmed with google Go for some time and moved to D for various reasons. It is true that unused imports and variables may be a hint that something was done wrong, or forgotten, and a review might be desirable. I am all for being warned about this. However, it is absolutely true that tagging those as errors can 1) become a nuisance when debugging 2) might not even be applicable for D (you mentioned some things about traits using them).

Now, the question became: "who's responsibility is it to warn about those messages?". I do like the idea of having an interface to the lexer and parser to make it easy for IDEs to identify those problems because 1) it makes finding those errors easier and 2) provides the possibility to move the responsibility from the compiler to another tool, which is flexible. If I am not mistaken, such an API is implemented in Go's standard lib.

So my take on this would be: give (not you personally) all the third party tools the means to identify those things easily because I am a 100% for the fact that those warnings CAN BE USEFUL.

By the way, would anyone be kind enough to tell me what UFCS are?

Phil

Never mind my last question. Found that it stands for: uniform function call syntax. Now I am going to look into what that means and how it affects the "no accessibility but visibility" thingy.

Ok so it's the feature that allows you to write something like myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.

I'd like to know if there is any functionality provided by having private functions/methods being visible? Does it mean you can override them in your module (for module scope privates)?

Thanks,

Phil

Ok so it's the feature that allows you to write something like
myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.

I'd like to know if there is any functionality provided by having
private functions/methods being visible? Does it mean you can
override them in your module (for module scope privates)?

Thanks,

Phil

On Sunday, December 23, 2012 21:36:34 Phil Lavoie wrote:
> Never mind my last question. Found that it stands for: uniform function call syntax. Now I am going to look into what that means and how it affects the "no accessibility but visibility" thingy.

It means that any free function can be called as if it were a member function of the type that it takes as its first argument. So, it's possible to do something like

auto result = range.find(subRange);

instead of

auto result = find(range, subRange);

For better or worse, you can even do things like

int i = 5.min(12);

As for accessibility, if I had

struct S
{
}

auto foo(S) {...}

and code which did

s.foo();

if I added a private function named foo to S

struct S
{
    private auto foo() {...}
}

then all of a sudden, the s.foo() call would be illegal, because in UFCS, the member function always wins when there's a conflict. However, if private were hidden (or at least didn't factor into overload sets), then s.foo() wouldn't break as long as it was outside of the module that S was in, because the foo function in S then wouldn't affect anything outside of that module, since it would be inaccessible to anything outside of that module.

- Jonathan M Davis

On Sunday, December 23, 2012 21:47:13 Phil Lavoie wrote:
> Ok so it's the feature that allows you to write something like
> myObject.notInClassDeclarationMethod( zeParam );
> Which is awesome.
> 
> I'd like to know if there is any functionality provided by having private functions/methods being visible? Does it mean you can override them in your module (for module scope privates)?

private is _always_ module scope.

Regardless can't override private functions even within a module, because in D, private and package functions are never virtual and therefore cannot be overridden. If you want to be able to override them, you have to make them public or protected.

In C++, you can make private functions virtual and override them, but that's not possible in D, primarily because we took the simpler route of tying the virtuality of a function to its access level rather than having to explicitly mark functions as virtual.

- Jonathan M Davis

> private is _always_ module scope.
Ooops I meant private functions inside a module. I was wondering if that would be allowed:

module a;
public auto aFunc( T )( T t ) { cantSeeMe( t ); }
private auto canSeeMe( SomeType t ) { ... }

module b;
import a;
alias a.canSeeMe canSeeMe
public auto canSeeMe( SomeOtherType t ) { ... } //Can this be called by afunc?

module c;

void main( ... ) {
  ...
  SomeOtherType t;
  t.aFunc();
  ...
}

If so, I am guessing it is made possible by said particularity?

Phil

On Sunday, December 23, 2012 22:12:17 Phil Lavoie wrote:
> > private is _always_ module scope.
> 
> Ooops I meant private functions inside a module. I was wondering if that would be allowed:
> 
> module a;
> public auto aFunc( T )( T t ) { cantSeeMe( t ); }
> private auto canSeeMe( SomeType t ) { ... }
> 
> module b;
> import a;
> alias a.canSeeMe canSeeMe
> public auto canSeeMe( SomeOtherType t ) { ... } //Can this be
> called by afunc?

No. cantSeeMe is looked up in aFunc's scope, which means that it sees a.cantSeeMe, not b.canSeeMe, so it'll call a.cantSeeMe. If b.cantSeeMe were called, it would be a compiler bug. Templates do symbol look up in their original scope, not in the scope that they're instantiated. They only do symbol lookup in the scope that they're instantiated in if they're mixed in, which you're obviously not doing here.

- Jonathan M Davis

In this case, I am convinced that there is no use of having the "no accessibility but visibility" particularity, because I cannot find any reason for it to stay like that (feature/exploit wise). On the other hand, I don't work on the compiler and I have no idea of what difficulties in would imply to change this. So the question I guess would be if changing its behaviour to make it predictable justifies the cost/work, for now (priority wise)?

On Sunday, December 23, 2012 23:34:41 Phil Lavoie wrote:
> In this case, I am convinced that there is no use of having the "no accessibility but visibility" particularity, because I cannot find any reason for it to stay like that (feature/exploit wise). On the other hand, I don't work on the compiler and I have no idea of what difficulties in would imply to change this. So the question I guess would be if changing its behaviour to make it predictable justifies the cost/work, for now (priority wise)?

If a function is truly hidden, then it wouldn't even be available for error messages and whatnot, and in some cases, it might be useful to give an error that a function is private rather than that it doesn't exist.

All we really need to do is make it so that inaccessible functions aren't put into overload sets. How big a change that is, I don't know, but it's not necessarily a small one, because right now, the access level is taken into account _after_ function overloading has been sorted out, and we'd have to change it so that it was taken into account before function overloading.

I wouldn't expect this to be a huge priority given some of what else needs to be done, but I really think that it should be fixed soon (prior to 2.062). The real trick is convincing Walter that it should be changed (though someone else like Kenji may end up actually implementing it).

- Jonathan M Davis