DirEntry isDir not working?

[Jonathan M Davis]

On Monday, February 25, 2013 13:34:04 monarch_dodra wrote:
> On Monday, 25 February 2013 at 08:20:31 UTC, Josh wrote:
> > [SNIP]
> > 
> > Josh
> 
> Seems like a massive bug in "DirEntry": It doesn't have a
> constructor, meaning anybody using "DirEntry" will actually get
> DirEntry.init.
> 
> The workaround is to use the function "dirEntry", which returns
> an initialized DirEntry.
> 
> This is pretty ridiculous, and I'm baffled no one has seen this
> yet. May I kindly ask you create a bug entry for this?

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. I don't know if that's a bug or not, though the fact that the 
fields in DirEntry are private and an implicit constructor still works seems 
distinctly off to me.

Regardless, as its currently implemented, clearly DirEntry was not meant be 
directly constructed (and it definitely was not meant to be directly 
constructed in its original form), so the fact that you can is a bug. It 
didn't even used to be that you could construct a single DirEntry except via 
dirEntries until I added that capability a while back, but I'm not quite sure 
why it doesn't use a constructor other than the fact that dirEntries doesn't, 
and all of the DirEntry code was thoroughly refactored a while back - mostly 
by me, but I don't remember much of the details of what changed anymore. Part 
of the problem probably resolves around the fact that it uses _init to 
initialize itself (which it's always done IIRC). That might be able to be 
changed to a constructor though. dirEntry matches dirEntries nicely, but I'm 
not sure that there's a technical reason at this point why DirEntry couldn't 
have a public constructor taking a string for the path.

- Jonathan M Davis