Hide module members #739

wants to merge 7 commits into


None yet
7 participants

MartinNowak commented Feb 19, 2012

  • restrict visibility of module level symbols to given access rights
  • restrict access rights when searching across imported modules

@MartinNowak MartinNowak referenced this pull request Feb 19, 2012


Fix imports #734


MartinNowak commented Feb 20, 2012

I eventually found the bug in the previous pulls. It was a missing 'return', which dmc nicely warned about. I also had to turn on optimizations when compiling dmd.


yebblies commented Feb 20, 2012

If only we had a better language that would catch these kinds of errors...


WalterBright commented Mar 19, 2012

  1. Need test cases to verify what it is doing.
  2. Does this address http://d.puremagic.com/issues/show_bug.cgi?id=313 ?
  3. What about http://d.puremagic.com/issues/show_bug.cgi?id=314 ?

MartinNowak commented Mar 19, 2012

This pull request is intended as a prerequisite for fixing protection and imports.
It is a protection fix and only addresses the issue that private symbols
can cause conflicts in dependent modules.

It is needed to fix selective imports properly IMO because access
checks alone would not solve ambiguities.

Does this address http://d.puremagic.com/issues/show_bug.cgi?id=313 ?

No, this needs a completely unrelated fix.

What about http://d.puremagic.com/issues/show_bug.cgi?id=314 ?

This is addressed by #734 which depends on this pull request.


MartinNowak commented Mar 19, 2012

There was an unrelated FreeBSD semaphore failure.


andralex commented Sep 25, 2012

LGTM, please review. Do we need changes to the documentation? I don't think we currently have a detailed explanation of protection rules, so it's a good opportunity to get a document in along with these fresh changes.

MartinNowak added some commits Feb 18, 2012

hide private/package module level symbols
- restrict visibility of module level symbols to given access rights

- restrict access rights when searching across imported modules
adapt search_correct
- find private symbols
- take first symbol for ambiguous proposals
- don't report errors for Scope::search_correct
more verbose search correct proposals
- print protection and kind
- print fully qualified name

andralex commented May 19, 2013



MartinNowak commented Jun 5, 2013

This pull contains a new approach on how overloads are handled.
Namely the visibility of an overload set is determined by the most visible overload.
After overload resolution we still perform an access check with the actual function.

That way overload resolution is not affected by the lookup origin which is an even bigger concern when the same concept is applied to struct/classes instead of modules. I hope I'll find some time to update DIP22 accordingly soon.

@dawgfoto please ping me when DIP22 description gets updated to match pull.


9rnsr commented Jul 18, 2013

The 'symbol visibility concept' is not bad, but Dsymbol::overprot is not good to me. Because it requires enumerating overload list at least twice, and it doesn't work for TemplateDeclaration. I think that protection checks should be delayed for isOverloadable symbols (they would be properly done in overloadApply and findTemplateDeclaration).


MartinNowak commented Jul 21, 2013

I also think that the same rules should apply for UDTs. That might require a little more thought so finishing DIP22 is the first step.


9rnsr commented Jul 21, 2013

What means "UDT" ?


MartinNowak commented Jul 21, 2013

User-Defined Type, i.e. structs and classes. I just added it to http://wiki.dlang.org/Commonly-Used_Acronyms.


quickfur commented Sep 6, 2013


Looks like this pull needs a rebase? I'd like to see this merged, as currently we have the ridiculous situation where private symbols in an imported module can conflict with public symbols imported from another module, when it should be clear that any reference to that symbol must refer to the public one. Specific example: std.regex declares a private symbol Stack, which means if you import another module with a public Stack, they will conflict.


MartinNowak commented Sep 6, 2013

That's the point. It's a huge problem, but I currently lack the time for this. It also requires a rewrite rather than a rebase, becase too much code changed in this area. Also we should first finish DIP22 and get it approved.


MartinNowak commented Nov 12, 2014

Closing this until we finish and approve DIP22. It's still a fundamental problem that needs to be addressed.

@MartinNowak MartinNowak referenced this pull request in dlang/druntime Sep 25, 2015


Rewrite `core.checkedint` functions. #1394

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment