Proposal: removeDirectoryRecursive should not follow symlinks

Bardur Arantsson spam at scientician.net
Tue Jan 6 14:59:36 UTC 2015


On 2015-01-06 14:57, Mike Meyer wrote:
> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> 
>> This is not a bugfix. A bug is failing to follow the functions
>> specification, which *does* include following symlinks.
>>
> 
> It's a bug in the design, not the code. The API it provides is useful, but
> dangerous and less useful than the safe version.
> 
> Breaking the API has been proposed. If we're going to do that, why not add
> a followSymlinks ::Bool argument as well, and document why the API was
> broken in this way. Going forward, at least. Not sure about backwards.
> 

Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
they think they do, they *really* don't. Any design which relies on it
is probably fundamentally broken. (If they're *really really* sure, they
can write their own.)

Btw, a Bool argumnent usually isn't a good idea. Better API design would be

   data SymlinkBehavior =
      FollowSymlinks
     | NoFollowSymlinks

(so that it's easy to tell at all call sites what it's doing.). However,
without default arguments this is forcing a pointless decision upon the
user, i.e. 99.9%+ of all usages should be using NoFollow, so why force
the user of the API to decide?

Even with such a change, I don't think the functionality should exist in
a "standard" library. (I won't repeat all the arguments; see the rest of
the thread :))

Regards,




More information about the Libraries mailing list