What is nothrow for?

[janderson]

Yigal Chripun wrote:
> Walter Bright wrote:
>> Janice Caron wrote:
>>> So I guess my question is, in what circumstance would "nothrow" be
>>> helpful? And is it helpful /enough/ to warrant "polluting" all library
>>> code with "nothrow" annotations?
>> "nothrow" is, as you say, a contract. It specifies that a function must
>> return normally (unless it aborts, crashes, or hangs). Such annotations:
>>
>> 1. improves the API documentation
>> 2. enables significantly better code generation (if you use a lot of
>> scope statements and struct destructors)
>> 3. nothrow can be very useful in building up transactions, because you
>> know that the components cannot fail
>> 4. destructors cannot throw exceptions (because they are already in
>> one). Andrei has proposed a method to deal with this, but it is as yet
>> unimplemented.
>>
>> For more info, see http://www.gotw.ca/gotw/082.htm and
>> http://www.boost.org/community/exception_safety.html
> 
> I'd like to point out that you both agree that "nothrow" is a
> _contract_. That immediately begs the question: why implement it as yet
> another ad hoc feature instead of making it part of D's DBC (which is
> yet to be implemented...)?
> 
> Personally, I don't see the point of constantly adding more annotations
> and keywords to D2 since it complicates the syntax and makes D2 much
> less attractive from a syntax POV.
> D2 will allow the following:
> pure invariant invariant(int) func(invariant(int)) nothrow;
> Am I the only one that thinks the above is too much?
> 
> It's time for a standardized Annotations/Attributes mechanism for D.
> I'll post my initial suggestion for such a mechanism in a new thread.
> 
> --Yigal


While attributes are a nice idea for somethings; for things like 
invariants it would make the client syntax more difficult to read.  Also 
invariant const etc.. could not go into the standard lib because then 
the compiler would make it much more difficult for the compiler to 
perform optimizations (Walters point 2).

Also it would be more difficult to extend the concept of invariants; for 
example, to something like functional programming because of attribute 
system limitations.

If your moving something like invariants to attributes, don't forget 
your not actually reducing the complexity to the end user.  Now they 
have to figure-out what the standard lib is doing also.  The complexity 
only reduces for the compiler writer.

-Joel