Christopher Blizzard wrote: >> right, one of the nice things about a flags-type attribute is that it >> is easily expandable without breaking binary compatibility. and, so >> provided the existing contract of the existing interface is not broken >> (ie. provided the meaning of the existing flags doesn't change) then >> everything should be okay. i agree with bbaetz: implementors must >> take care to only check the bits they know/care about. flags-type >> attributes give us some flexibility moving forward without paying the >> penalty of extra QI's in our code. > > Binary compatibility isn't the only thing we have to worry about here, > guys. There's this contract thing.
...which is why I argued, so long ago, that we needed to sort out things like startup, shutdown, and per-instance/contract threadsafety stuff before we declared things "frozen". I was alone on that, though, so I've stopped pushing. Mike
