On 12/24/12 06:20, Martin Nowak wrote:
> On 12/23/12 03:35, 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++:
>
> Yeah, and it must stay one for D overload sets too.
> In my pull request I always used the most accessible protection for the
> visibility of an overload set without removing the access check after
> overload resolution.
>
> http://dlang.org/hijack.html
> https://github.com/D-Programming-Language/dmd/pull/739
>
Let me clarify the HideModuleMembers pull request.

Symbols with private protection are hidden when searching through imported modules.
Symbols with package protection are hidden when searching through imported modules from a different package.
The visibility of an overload set is determined by it's most visible member.
Protection does NOT alter overload resolution, i.e. matching within a visible overload set.
Members of classes and structs are always visible.

This mainly fixes #1238, i.e. name collisions in non static imports.
http://d.puremagic.com/issues/show_bug.cgi?id=1238

On 12/24/12 6:20 AM, Jacob Carlborg wrote:
> On 2012-12-24 01:11, Walter Bright wrote:
>
>> 1. what access means at module scope
>> 2. at class scope
>> 3. at template mixin scope
>> 4. backwards compatibility
>> 5. overloading at each scope level and the interactions with access
>> 6. I'd also throw in getting rid of the "protected" access attribute
>> completely, as I've seen debate over that being a useless idea
>> 7. there's also some debate about what "package" should mean
>
> I also want to add:
>
> 8. Investigate the usefulness and possibility to combine multiple access
> attributes for more fine grained control, i.e. using "package" and
> "protected" on a single declaration

Has anyone started a DIP on this? Let's not let things scroll away from the institutional memory.

Andrei

On Sunday, 23 December 2012 at 19:55:15 UTC, Jonathan M Davis wrote:
> 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

I stopped all work on that and am waiting for it. I've done a crappy wrapper around some existing code on the subject. I'd love you if something come out of your project !

On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
> Has anyone started a DIP on this? Let's not let things scroll away from the institutional memory.

I've only gotten as far as thinking about it and leaving the relevant e-mails marked as unread.

- Jonathan M Davis

On 12/28/12 4:45 PM, Jonathan M Davis wrote:
> On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
>> Has anyone started a DIP on this? Let's not let things scroll away from
>> the institutional memory.
>
> I've only gotten as far as thinking about it and leaving the relevant e-mails
> marked as unread.

Well given your passion in the matter I'd say everybody is waiting on the proverbial poster (i.e. you) to deliver!

Andrei

On Friday, 28 December 2012 at 21:12:48 UTC, Andrei Alexandrescu wrote:
> On 12/24/12 6:20 AM, Jacob Carlborg wrote:
>> On 2012-12-24 01:11, Walter Bright wrote:
>>
>>> 1. what access means at module scope
>>> 2. at class scope
>>> 3. at template mixin scope
>>> 4. backwards compatibility
>>> 5. overloading at each scope level and the interactions with access
>>> 6. I'd also throw in getting rid of the "protected" access attribute
>>> completely, as I've seen debate over that being a useless idea
>>> 7. there's also some debate about what "package" should mean
>>
>> I also want to add:
>>
>> 8. Investigate the usefulness and possibility to combine multiple access
>> attributes for more fine grained control, i.e. using "package" and
>> "protected" on a single declaration
>
> Has anyone started a DIP on this? Let's not let things scroll away from the institutional memory.
>
> Andrei

I feel like the issue is much deeper. I have no clue what the priorities are when resolving some identifiers, and the doc is unclear about it, and dmd is sometime inconsistent, or some other time don't implement the feature (for instance multiple alias this).

In a.b , b can be :
 1 a member of a.
 2 a member of an alias this of a.
 3 any recursion of the case 2.
 4 an UFCS function.
 5 an UFCS function using an alias this of a as argument.
 6 any recursion of 5.
 7 an imported symbol at scope level.
 8 repeat 4, 5 and 6 with that imported symbol.
 9 an imported symbol at module level.
 10 repeat 4, 5 and 6 with that imported symbol.
 11 all cases I have forgotten as I wrote that quickly.

It is unclear when they take priorities over each other and when they collide. Visibility is another variable to the equation, but in a first place, this is unclear without them.

On 12/22/2012 1:29 AM, "Jérôme M. Berger" wrote:
> Walter Bright wrote:
>> It's that way in C++ mainly so that it doesn't make the already complex
>> overloading system even more so. And in 25 years of working with C++,
>> I've never seen this make anyone's list of horrible things about C++.
>>
> 	Actually, it is *not* that way in C++ for "module-private"
> functions. I know that C++ doesn't have true "modules" and a
> fortiori true "module-private" functions (or types or variables),
> but the C++ equivalent of module-private is file static (or the
> anonymous namespace) and those do *not* make it into the overload
> set and cannot affect user code.

I was talking about inside struct/class scope.

On Friday, December 28, 2012 16:52:32 Andrei Alexandrescu wrote:
> On 12/28/12 4:45 PM, Jonathan M Davis wrote:
> > On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
> >> Has anyone started a DIP on this? Let's not let things scroll away from the institutional memory.
> > 
> > I've only gotten as far as thinking about it and leaving the relevant e-mails marked as unread.
> 
> Well given your passion in the matter I'd say everybody is waiting on the proverbial poster (i.e. you) to deliver!

The wiki.dlang.org DIP page claims that it's only a placeholder page (until all of them are copied over?). So, should I put the new DIP in both places, or should I just put it on the new one in spite of the fact that it claims that it's a placeholder?

http://wiki.dlang.org/DIPs http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

- Jonathan M Davis

On Monday, 24 December 2012 at 15:36:47 UTC, Jonathan M Davis wrote:
> I believe that C# did something similar. It would certainly solve the question
> of package's virtuality quite nicely and wouldn't change any existing code,
> just allow for those who want virtual package functions to have them.
>

Stopping to conflate visibility with virtuality would solve it in a more simple way.