Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

issue 15371 - some traits should bypass the protection #5289

Closed
wants to merge 2 commits into from
Closed

issue 15371 - some traits should bypass the protection #5289

wants to merge 2 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Nov 30, 2015

The argumentation is in the bug tracker issue, but in short:

"__traits(getMember,...)" should always work, whatever is the member protection (as long as the symbol is a valid one).

The current limitation is problematic because it prevents to write functions related to traits in a separate dedicated modules (e.g mylib.traits)

See also this issue, it demonstrates why it could be interesting to give super-powers to traits: because the current limitation already affects phobos.

@adamdruppe
Copy link
Contributor

This could fix my mistake with getProtection too which requires a symbol... which you can't get on private members right now.

@AndrejMitrovic
Copy link
Contributor

This seems like something that requires approval. Also, would this allow someone to call a private function from another module?

Ping @WalterBright @andralex for thoughts.

@ghost
Copy link

ghost commented May 19, 2016

Yes this would allow things that are completly illegal, but this is the point. The idea is to allow this with a kind of caution, e.g use this only if you know what you do because it can break the protection.

I'm curious to know if there could be another way to solve the problem exposed in the bugzilla issue (other than mixing a template to get the scope).

@WalterBright
Copy link
Member

Maybe it would make sense to bypass the protection if one is not in @safe code.

@aubade
Copy link

aubade commented Jul 19, 2016

Isn't @safe supposed to be about one specific thing (memory corruption)? Expanding it to mean "potentially poor programming practices" seems a very hazard-laden road to take

@dnadlinger
Copy link
Member

Isn't @safe supposed to be about one specific thing (memory corruption)? Expanding it to mean "potentially poor programming practices" seems a very hazard-laden road to take

The connection to @safe is that accessing private members might invalidate state that a certain type relies on to provide safety guarantees. For example, a member function might be @trusted on grounds that the class has previously made sure some private pointer members are in a certain well-defined state.

@ghost
Copy link

ghost commented Aug 30, 2016

You can close this PR, bugzilla issue is closed because of #6078

@JinShil
Copy link
Contributor

JinShil commented Jan 19, 2018

See also comments starting here: #7241 (comment)

@RazvanN7
Copy link
Contributor

Closing this as 2 other PRs have been submitted for this:

#9325
#9585

@RazvanN7 RazvanN7 closed this Apr 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants