What is the rationale behind std.file.setAttributes ?

[Andrei Alexandrescu]

On 12/27/13 3:12 AM, Marco Leise wrote:
> I know that code is from Martin, and I don't mean this as
> pointing with the finger. There are code reviews, too.

True. Once code is accepted it is owned by the team.

> This is a case of the proverbial thin wrapper around a system
> function, as public API of Phobos. Amongst the large set of
> operating system abstractions, this one is somewhat deceiving,
> because it looks the same on each platform, but the parameter
> has a different meaning on each system. Instead of taking e.g.
> octal!777 it should really be a D specific enum, IMHO. It is a
> coincidence that both Windows and POSIX use a 32-bit integer
> for file attributes, but not technically sound to confuse them
> in a public API.

I also dislike the integer-based std.file API. The layout of the 
integral is inherently system-dependent so almost all code based on it 
is non-portable unless it uses more ad-hoc APIs (such as attrIsFile). My 
recent work on rdmd has revealed the std.file attribute APIs sorely wanting.

I picture two ways out of this:

1. Improve the DirEntry abstraction by e.g. allowing it to fetch 
attributes only etc.

2. Define a ligthly structure FileAttributes structure that encapsulates 
the integral and offers portable queries such as isDir, isFile etc.

Any takers?

As a general note, we are suffering from an deflation of reviewers 
compared to contributors. I've looked at Phobos closely again in the 
past couple of weeks and saw quite a few things in there that I wouldn't 
have approved. On the other hand, nobody can be expected to babysit 
Phobos 24/7 so the right response would be closer scrutiny of pull 
requests by the entire community. To foster that, one possibility would 
be to automatically post new pull requests to this group. What do you 
all think?


Thanks,

Andrei