What is the rationale behind std.file.setAttributes ?

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Saturday, 28 December 2013 at 08:18:44 UTC, Jonathan M Davis 
wrote:
> on it specifically. My main point was that some stuff in 
> std.file is system-
> specific and that if it has to be, it's better to have it in 
> std.file as system-
> specific rather than not having it at all just because it 
> couldn't be
> completely cross-platform and portable. So, just because 
> setFileAttributes is
> doing something system-specific does not mean that it's bad.

It is bad. If you want system-specific behaviour you should have 
a separate interface that provide all the advantages that going 
to a lower level provides. Having half-assed OS-specific support 
is too pragmatic and will lead to a legacy mess in the long run 
when those interfaces become obsolete.

A good file abstraction should also support newer file systems 
like Google Cloud Storage, though. GCS does not support append() 
or directories.

A good file abstraction should also provide mechanisms to deal 
with different levels of consistency on the underlying filesystem 
and caching-mechanism:
- read after write might return an old version
- read after write returns the new version if read from the same 
computer
- read after write always returns the new version

As a new language D should support Cloud based environments 
out-of-the-box with a hierarchy of functionality down to the 
peculiarities of Windows/Posix etc so that you can decide to code 
in a manner that supports all platforms without having to litter 
your code with ifs and version-statements… and also restrict you 
to the subset you have "authorized" so that you can develop on 
your Windows system and port it to the cloud with just a 
recompile without knowing the details of the cloud file system. 
(i.e. the compiler warns you when you are using system specific 
functionality).

I also think good file system support implies built-in caching 
and let the library decide whether to turn library-level caching 
on or off based on what the operating system or underlying 
interface supports. E.g. the ability to tell the system that you 
want successive reads of a file to be available fast at the cost 
of consistency.