Proposal for Requiring Save/Restore of Sets and Tags

[Jason Kraftcheck]

On 10/21/2010 11:35 AM, Carl Ollivier-Gooch wrote:

> 
> It's possible that it's a useful capability, but it's semantically
> incompatible with either of the two mechanisms we currently have
> (subset/set membership and parent/child).  Semantically, the only way to
> have a cycle there is something as silly as set A is an improper subset
> of B is an improper subset of A --- with A and B necessarily identical
> sets.  Parent-child relationships can't semantically have cycles at all.
> 

So we have a capability to construct graphs of sets (parent/child links).
We have functions for querying and manipulating such links named in
accordance with or initial intended uses.  Your argument is to constrain the
functionality based on a semantic argument about the function names.
Wouldn’t it be better (cost nothing and not limit future functionality) to
just rename the functions?  By why even do that?  I just don't see the
problem with a) having this functionality (or at least not prohibiting us
from providing it) and b) naming the functions in such a way as to be least
confusing for the majority of uses.

> 
> My memory is that we had already agreed that an implementation is free
> to skip expensive (and even cheap) checks when compiled in release mode,
> though it should do all checks in debug mode.  The latter is very
> important to help developers debug code, but once it's working (i.e.,
> nothing stupid being done by accident), a lot of those checks are
> unnecessary, so turning them off for release code is no problem.
> Conditionally-defined macros will do this.  As Mark said, there are
> run-time configurable methods for this, too, though I suspect they add a
> small amount of overhead in practice.
> 

You are stating that implementations must conform to a standard behavior of
prohibiting cyclical links.  And then recommending that we disable such
restrictions in the version/build of the code that will be used in practice.
 Then why even make this a requirement?  What's the point of making us jump
through hoops implementing a "strict conformance" build that will only be
used in practice with the conformance tests?  How much code can we change
between the two?  Would instead building a copy of the reference
implementation if strict conformance is requested be okay?

- jason