> But now that I think about it, I'm wondering whether a TS, since
> it really
> is optional, should specify its own feature-testing method.
> Comments?
>
> I just realized that I fairly urgently need to talk to Beman about
> the
> filesystem TS, since it has been voted out of WG21. I hope that a
> window of
> opportunity hasn't already closed.

I just chatted with Beman. He pointed out that a library TS typically uses
inline namespaces to do versioning/disambiguation, and at least in the case
of filesystem, there is an expectation that the TS itself will eventually be
revised to add new features. He also said that he doesn't feel it's too late
to add version-testing to the TS that's already in flight.

He intends to take it up in LEWG/SG3 first thing this morning, and said that
Jeffrey, as LEWG chair, would be very interested in the topic.


Given that the primary reason for putting the feature-test macros into a
document separate from the standard was to avoid even the impression that
standard features are optional, and that features described in a TS are by
definition optional, it seems clear to me that the case for putting
feature-testing facilities for a TS in a different document is weak at best.

For a library-only TS, of which we have several, I guess this is going to be
discussed in LEWG this morning. Friday morning I'm going to be presenting to
EWG about CPLEX. Hopefully at that time I'll also be able to raise the
question of feature-testing for a TS with a language feature -- of which
there are already a few in the works (runtime-arrays, concepts, TM).

Clark