digitalmars.D.bugs - [Issue 10861] New: Compiler should disallow field initialization for inaccessible fields
- d-bugmail puremagic.com (67/68) Aug 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10861
http://d.puremagic.com/issues/show_bug.cgi?id=10861 Summary: Compiler should disallow field initialization for inaccessible fields Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: andrej.mitrovich gmail.com 12:23:31 PDT --- ----- module foo; struct S { int x; int y; private: int _special; } ----- ----- module test; import foo; void main() { auto s = S(1, 2, 3); } ----- $ dmd -c test.dThe _special field was initialized, even though it's not an accessible field from the 'test' module. I think this is an oversight that we could fix. The workaround is to define a custom ctor, although this might be tedious if all that's needed is basic field initialization. But note that there are edge cases if we try to implement this. For example: ----- module foo; struct S { int x; int y; private int _special; int z; } ----- ---- module test; import foo; void main() { auto s = S(1, 2, 3); } ---- If we forbid field initialization of private variables, does the above make 'z' equal to 3 (in other words, _special is simply skipped over), or does the compiler simply generate an error stating _special cannot be initialized from the 'test' module? I think the simplest and safest implementation is to always attempt field initialization in the order of the declarations, without hiding inaccessible fields, so the above code would produce an error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 20 2013