On Wed, Aug 19, 2009 at 11:08 PM, Chris Lattner<clattner at apple.com> wrote:> > As we discussed on IRC, I don't think there is any reason for the > implementation of these methods to check these invariants. These are clear > API invariants that the caller can check if needbe. Making the > implementation check these will slow down clients which are known to be well > formed. I didn't look at all of the things you listed, perhaps some other > ones would make some more to be recoverable errors.By that logic, I think it's safe to say then to say that it's an invariant of APInt and APFloat to pass in a well formed string, and that it's the client's responsibility to make sure that the string isn't invalid. Which then follows that the assertions checking the validity of the string should stay. I'm happy with that decision if you are.
On Aug 19, 2009, at 11:19 PM, Erick Tryzelaar wrote:> On Wed, Aug 19, 2009 at 11:08 PM, Chris Lattner<clattner at apple.com> > wrote: >> >> As we discussed on IRC, I don't think there is any reason for the >> implementation of these methods to check these invariants. These >> are clear >> API invariants that the caller can check if needbe. Making the >> implementation check these will slow down clients which are known >> to be well >> formed. I didn't look at all of the things you listed, perhaps >> some other >> ones would make some more to be recoverable errors. > > By that logic, I think it's safe to say then to say that it's an > invariant of APInt and APFloat to pass in a well formed string, and > that it's the client's responsibility to make sure that the string > isn't invalid. Which then follows that the assertions checking the > validity of the string should stay.You're right that anything can be declared to be a property the caller needs to enforce. This makes it a muddy issue that boils down to a judgement call based on how low-level the API is and how complex the invariant is. Two examples: Since APInt is a very low level class, bitwidth is something clients can be expected to have to know about. Since detecting errors in floating point string literals basically requires parsing the whole string, so making clients enforce all the invariants would basically make a string literal parsing routine useless. Something like 'parsing a string' is also inherently an operation that can fail if the input is malformed, so returning an error code makes sense. Does this rationale seem reasonable to you? -Chris
On Wed, Aug 19, 2009 at 11:24 PM, Chris Lattner<clattner at apple.com> wrote:> > You're right that anything can be declared to be a property the caller needs > to enforce. This makes it a muddy issue that boils down to a judgement call > based on how low-level the API is and how complex the invariant is. > > Two examples: > > Since APInt is a very low level class, bitwidth is something clients can be > expected to have to know about. > > Since detecting errors in floating point string literals basically requires > parsing the whole string, so making clients enforce all the invariants would > basically make a string literal parsing routine useless. Something like > 'parsing a string' is also inherently an operation that can fail if the > input is malformed, so returning an error code makes sense. > > Does this rationale seem reasonable to you?Sure, that sounds good. I'll put together a patch for returning error codes for the string parsing, but leave the rest as asserts.