[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 Basile-z changed: What|Removed |Added CC|b2.t...@gmx.com | --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 --- Comment #8 from Basile-z --- Created attachment 1772 --> https://issues.dlang.org/attachment.cgi?id=1772&action=edit fix proposal --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 Basile-z changed: What|Removed |Added Keywords||patch --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 --- Comment #7 from dran...@gmail.com --- std.experimental.typecons.Final is also affected, since its implementation uses Proxy the same way. I should probably change the title for a more general one. --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 --- Comment #6 from dran...@gmail.com --- (In reply to Martin Nowak from comment #5) > I'm for reverting this change (the Proxy part). I agree. But I suggest reverting all of PR #4763: the Proxy part and the destroy part. The latter also because it introduces undeterministic destruction of Unique!structs (see [1], there is no bug report for this yet, I guess). [1] http://forum.dlang.org/post/ixxkijrdlffflfzkk...@forum.dlang.org --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #5 from Martin Nowak ---
I'm for reverting this change (the Proxy part).
Proxy is a horrible hack that employ a giant template machinery and was only
introduced to replace typedef. It's main difference from alias this being, that
you cannot implicitly convert it to the type.
Unique should work like this, but cannot until -dip1000 became default.
static if (class_or_interface)
T get() return scope { return _p; }
else
ref T get() return { return *_p; }
alias this get;
This does allow implicit conversion, but binds the lifetime of the returned
class ref/ref to the lifetime of Unique, thus making it impossible to escape.
It'll still take a while until that works, and we're likely to come up with new
RC implementations after that (b/c both Unique and RefCounted leave a lot to
wish).
Also opDot isn't going away for a while (and maybe be could be replaced with
opDispatch).
See https://trello.com/c/pTlDuyBD/31-finish-smartref-implementation for
previous attempts on fixing Unique/RefCounted.
--
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 --- Comment #4 from dran...@gmail.com --- (In reply to b2.temp from comment #3) > (In reply to dransic from comment #2) > > Private members are supposed to be accessible in the module where the type > > is declared (module-level encapsulation). > > [...] > > --- > > There's a bigger underlying problem. Clearly something is broken by the > change but the change doesn't work because Proxy uses __traits() and > __traits() has a limitation related to the protection attributes. I don't > know if you've followed the NG discussions last months but there's been > several topics about this. A semantic change is even planned for the next 6 > months (see the recent announce about H1) > > That being said I don't suggest to wait the semantic change to happen. I > just come because this __traits() thing has been a personal concern. OK, thanks. I didn't know about these discussions about __traits() and I see now why Proxy doesn't work. So there's a plan to allow __traits() to bypass access rules to provide more useful introspection. That's good. Maybe we should have waited for this change before switching to a new implementation of `Unique`. --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 b2.t...@gmx.com changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #3 from b2.t...@gmx.com --- (In reply to dransic from comment #2) > Private members are supposed to be accessible in the module where the type > is declared (module-level encapsulation). > [...] > --- There's a bigger underlying problem. Clearly something is broken by the change but the change doesn't work because Proxy uses __traits() and __traits() has a limitation related to the protection attributes. I don't know if you've followed the NG discussions last months but there's been several topics about this. A semantic change is even planned for the next 6 months (see the recent announce about H1) That being said I don't suggest to wait the semantic change to happen. I just come because this __traits() thing has been a personal concern. --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065
--- Comment #2 from dran...@gmail.com ---
(In reply to greenify from comment #1)
> > If this behaviour is intended, the doc should state it.
>
> This should definitely have gotten a proper changelog entry (and deprecation
> warning).
> However, I am not really convinced that it should be noted in the
> documentation that access to private member variables isn't supported as
> this is the way visibility is supposed to work in D. Did anything lead you
> to this assumption or was it just by chance that accessing `private`
> variables worked and you didn't realize until the hole was fixed?
Private members are supposed to be accessible in the module where the type is
declared (module-level encapsulation). A type constructor like `Unique` should
return a type with the same access behavior. RefCounted works as I expect (but
maybe I have wrong expectations...):
---
import std.typecons : RefCounted;
struct Foo
{
private int i;
}
void main()
{
RefCounted!Foo foo = Foo(1);
foo.i = 2; // OK
}
---
--
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 --- Comment #1 from greenify --- > If this behaviour is intended, the doc should state it. This should definitely have gotten a proper changelog entry (and deprecation warning). However, I am not really convinced that it should be noted in the documentation that access to private member variables isn't supported as this is the way visibility is supposed to work in D. Did anything lead you to this assumption or was it just by chance that accessing `private` variables worked and you didn't realize until the hole was fixed? --
[Issue 17065] [REG2.072] Unique does not work with private members
https://issues.dlang.org/show_bug.cgi?id=17065 Martin Krejcirik changed: What|Removed |Added Summary|Unique does not work with |[REG2.072] Unique does not |private members |work with private members --
