On Monday, 25 February 2013 at 18:23:52 UTC, Jonathan M Davis
wrote:
What I find most odd is that DirEntry("foo") even compiles.
It's not giving you
DirEntry.init. It's giving you a DirEntry with its first field
initialized
(which happens to be its name, but that could theoretically
change, since
that's an implementation detail) but with every other field
being its init
value. Basically
struct S
{
int i;
string s;
}
auto s = S(5);
compiles. I would have thought that the compiler would require
that you
provide every value if you were using an implicit constructor
like that, but
apparently not.
[SNIP]
- Jonathan M Davis
No, that's just partial agglomerate construction, and has always
worked that way. I think it works that way in C++ too, but I'm
not sure (I seldom use POD in C++).
What I *am* surprised by though is that it also works with
private fields. I'd have expected an "_name is private" compile
error. I should create a bug entry, but I kind of expect walter
to reply "works as intended"...
Since you are the one that refactored, what was the point of
those _init functions? Wouldn't they have better worked as
private constructors?
