[Issue 10861] New: Compiler should disallow field initialization for inaccessible fields
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Tue Aug 20 12:23:33 PDT 2013
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 at puremagic.com
ReportedBy: andrej.mitrovich at gmail.com
--- Comment #0 from Andrej Mitrovic <andrej.mitrovich at gmail.com> 2013-08-20 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.d
>
The _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: -------
More information about the Digitalmars-d-bugs
mailing list