Is the lack of "noexcept" for functions with undefined behavior intentional?

[Daryle Walker]

I'm writing a proposal and I see a set of member functions like this:

 

constexpr bool empty() const noexcept;

reference operator[](size_type n);

constexpr const_reference operator[](size_type n) const;

reference at(size_type n);

constexpr const_reference at(size_type n) const;

reference front();

constexpr const_reference front() const;

reference back();

constexpr const_reference back() const;

T * data() noexcept;

 

 

I noticed that the element access methods do not have noexcept marked, although their (most likely) implementations could support it[1]. Then I realized that they all have undefined behavior when the container is empty (or the given index is too high), even if the actual access (when the element exists) can be done no-throw. Is that intentional, although undefined behavior shouldn't affect non-throwability. Is it to allow debugging-mode accesses that could throw?

[1] Besides "at," which is made to throw upon out-of-bounds errors.
 

[Daniel Krügler]

2013/9/6 Daryle Walker <dar...@gmail.com>:

Exactly, these functions which have a so-called "narrow contract"
(contrast these to functions with "wide contract" such as size(),
empty(), etc), therefore the standard library specification does not
add an explicit noexcept specifier for functions with narrow contract,
because we want to allow implementations to throw an exception *in
case of a contract violation*. Of-course a feasible implementation
could simply mark these functions with noexcept and assert. You should
explicitly specify:

Throws: Nothing

for functions with narrow contract that won't throw an exception
within the contract boundaries.

- Daniel

[David Rodríguez Ibeas]

I believe that to be the case. John Lakos mentioned that there was a major rewrite of the 'nothrow' guarantees to allow implementations to throw when detecting undefined behavior. It might be worth to reference N3604 here, since it proposes a framework to make use of this 'feature'.

--
 
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussio...@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.

[jonatha...@gmail.com]

The rule throughout the library is that a function with preconditions (aka a "narrow contract") must not be unconditionally noexcept (in part this is to allow debugging implementations to use exceptions to report precondition violations.)

Functions with no preconditions (aka a "wide contract") can be unconditionally noexcept.

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf for more details.

Not everyone likes this rule :-)

 

[Ville Voutilainen]

On 6 September 2013 18:31, <jonatha...@gmail.com> wrote:

The rule throughout the library is that a function with preconditions (aka a "narrow contract") must not be unconditionally noexcept (in part this is to allow debugging implementations to use exceptions to report precondition violations.)

Functions with no preconditions (aka a "wide contract") can be unconditionally noexcept.

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf for more details.

Not everyone likes this rule :-)

Not everyone has to like it, but John is, in this case, right. ;) It takes a while to stomach, but I haven't been
able to convince myself otherwise once I grokked the reasoning.