Concerning future APIs:

While the implementations of future APIs and SRFI 170 may not be
independent (or even may not even be able to be independent), this
doesn't mean that the APIs must be dependent.

It would be a mistake to put procedures into the user-visible API of
SRFI 170 just so that other POSIXy SRFI's do not have to know about
the internals of a particular implementation of SRFI 170 in order to
be implemented. If there are implementation dependencies, the
implementation will just have to be shipped together (and build upon
some lower-level, implementation-defined, non-standardized common
layer). This will be inevitable in any case as soon as we talk about
thread safety in future APIs, whose implementations will probably be
intimately tied to the implementation of, say, SRFI 18 (or whatever
multithreaded support there is).

Am Fr., 11. Sept. 2020 um 15:16 Uhr schrieb <xxxxxx@ancell-ent.com>:

> The reverse is messy, in that I can envision future libraries and SRFIs creating fds, wanting to take advantage of the GC-ing benefit of FDOs, and wanting to call SRFI 170 procedures that take either.  Without SRFI 170 exposing the FDO record triplet of fdo?, make-fdo/fd->fdo, and fdo->fd, they'll have to roll their own, and call their own fdo->fd before calling a SRFI 170 procedure that takes either because the FDO types will be disjoint.  While you could view that as a safety measure for SRFI 170 implementations where FDOs are unwrapped exact integers like my current Chibi Scheme sample implementation, well, again, it's messy.
>
> Can't yet think of good answers to these issues, nothing that isn't also messy and requiring extra work from the user and/or SRFI 170 implementor.  So one question to ask, is the value add of FDOs being GC-able worth the extra complexity, especially without mandatory closing of the fd on GC?

Implementations may want to reuse file descriptors. For that, it is
important for them to know, which file descriptors are in use and
which are not. The opaque FDOs seem to solve this problem perfectly.

Marc