View mode: basic / threaded / horizontal-split · Log in · Help
December 23, 2012
Re: About Go, D module naming
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
December 23, 2012
Re: About Go, D module naming
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.
December 23, 2012
Re: About Go, D module naming
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
December 23, 2012
Re: About Go, D module naming
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
December 23, 2012
Re: About Go, D module naming
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
December 23, 2012
Re: About Go, D module naming
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
December 23, 2012
Re: About Go, D module naming
> 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
December 23, 2012
Re: About Go, D module naming
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
December 23, 2012
Re: About Go, D module naming
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)?
December 23, 2012
Re: About Go, D module naming
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
5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home