Bug 10996 – Subtyping with "alias this" conflicts with private base type

Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-09-08T04:46:17Z
Last change time
2018-10-23T12:47:08Z
Assigned to
No Owner
Creator
Joseph Rushton Wakeling

Attachments

IDFilenameSummaryContent-TypeSize
1246subtype.dModule defining a simple subtype.text/x-dsrc264
1247subtypemain.dMain program file that imports the subtype module. Run to see the bug in action.text/x-dsrc114

Comments

Comment #0 by joseph.wakeling — 2013-09-08T04:46:17Z
Created attachment 1246 Module defining a simple subtype. Consider a simple subtyping example, in the spirit of that given on TDPL p. 231. class Foo { public int a; } class Bar { private Foo _base; alias _base this; this() { _base = new Foo; } } Theoretically, the public member .a of Foo should be publicly available via Bar, as the alias itself is public. However, in practice, any attempt to access it from outside the module will result in an error: Error: class subtype.Bar member _base is not accessible Full example code is attached -- run rdmd -main -unittest subtype.d ... to see how access to Bar.a works from within the module, and then rdmd subtypemain.d ... to see it failing when accessed from outside. The ability to have a private instance of the base type is clearly desirable because you don't want the user to be able to access Bar._base directly. However, the public alias should mean that public methods of _base are made public via Bar's interface.
Comment #1 by joseph.wakeling — 2013-09-08T04:47:10Z
Created attachment 1247 Main program file that imports the subtype module. Run to see the bug in action.
Comment #2 by joseph.wakeling — 2013-09-17T03:09:41Z
The issue also affects module-level aliases, e.g.: alias fun = Impl!int; private template Impl(T) { void Impl(){} } See: http://forum.dlang.org/thread/[email protected] Example benefit for this kind of aliasing: the programmer can define a private implementation that takes a variety of template parameters, and make publicly available only instantiations with a sane choice of parameter values (could be useful for e.g. random number generators).
Comment #3 by bearophile_hugs — 2014-07-10T11:33:32Z
Comment #4 by joseph.wakeling — 2014-07-10T20:19:29Z
Thanks for linking in the discussion. I'm feeling rather sad that this issue doesn't appear to be getting any attention. :-(
Comment #5 by bearophile_hugs — 2014-07-10T20:46:22Z
(In reply to Joseph Rushton Wakeling from comment #4) > Thanks for linking in the discussion. I'm feeling rather sad that this > issue doesn't appear to be getting any attention. :-( There are about 2000 issues that are not getting attention... So you need to be patient, or to try to create a patch yourself.
Comment #6 by razvan.nitu1305 — 2018-10-23T12:47:08Z
Storage class modifiers are ignored for alias this. The alias this simply forwards undefined lookups to the the aliased member. So the following code: Bar b = new Bar(); b.a = 10; is actually lowered to: b._base.a = 10; If you are in the same module as the declaration of Bar, that's fine. Otherwise, you will get an error which is the correct behavior. See Walter's comment on [1]. Closing as invalid. [1] https://issues.dlang.org/show_bug.cgi?id=10692