On 2011-06-09 13:19, Andrei Alexandrescu wrote: > Both listDir and listdir should go.
Quite possibly. But there are several versions of listdir and not all of them were marked as being supposed to be deprecated. In fact, glancing at std.file, it looks like only the version which took a delegate was marked as supposed to be deprecated. So, I renamed that one to _listDir and made it private (since dirEntries need it) and marked the old one as scheduled for deprecation. The overloads which hadn't been marked as supposed to be deprecated, I renamed to listDir (and scheduled the old versions for deprecation). So, I just went with what the documentation had previously said about deprecation. I don't know if we want to get rid of all of the public versions of listdir/listDir or not. They provide a different set of functionality than dirEntries does. Of course, the version which is fully currently scheduled for deprecation rather than being renamed is the most versatile (the one which takes a delegate) - it's also the one that needs to be around for dirEntries unless it's just completely redesigned. The overload which takes a path is only useful insomuch as it's probably a bit more efficient than call dirEntries, so it should probably go. The other two take a pattern and a RegEx respectively, and so getting rid of them would certainly reduce functionality further, but in all cases, you could simply iterate with dirEntries and check each file individually as to whether it matches what you want (more verbose, but not a huge deal). So, if you want to get rid of all public versions of listdir and listDir, that's fine with me. I don't personally use any of them anyway, but what's currently there is based on what the documentation previously said about deprecation. - Jonathan M Davis _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
