[LLVMdev] error api for APInt / APFloat

[Chris Lattner]

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