Re: [SUGGESTION] Some lfs functionality in os library, please!

[Paul Moore <p.f.moore@...>]

On 7 September 2016 at 16:00, Peter Aronoff <telemachus@arpinum.org> wrote:
> Bottom line: I don’t think problems with other standard libraries are
> a knockdown argument against including some (relatively?) basic os-related
> functions into Lua’s small stdlib.

OTOH, if the suggested libraries are inappropriate (for whatever
reason) in a particular application, it's much harder to omit/disable
them if they are in the stdlib. I had this problem very recently, the
os functions don't handle Unicode correctly on Windows (nor does print
for that matter) and it's a real pain to disable them.

Looking at the OP's first suggestion, does lfs.dir correctly handle a
directory containing a filename that's not encodable in the current
codepage on Windows? Sure it's (to an extent) a specialist case, but
it matters a lot to some applications.

There's a trade-off here. If it's easy to ignore a library (just don't
use it) then it's OK for it to not cover all cases. But if it's hard
to ignore it (it's built into the language or stdlib) then you have a
greater responsibility to work correctly for all your users. Of course
Lua already defers to the CRT for whether things like getenv, popen,
io or print are "correct". But once we get out of the C standard
library, things get progressively murkier.

Paul