Remove noexcept from ParallelIndexSet::operator[]

While it does not throw an exception, it does call std::vector::operator[] that has no noexcept specifier and therefore might throw.

This reverts parts of MR !236 (merged) and is inspired by @carsten.graeser's comment. I agree with him that we should be careful with noexcept specifiers. Not sure whether we should revert the added specifiers also in timer.hh. I did not do that as they either call C functions or noexcept C++ ones.

According to the documentation the noexcept should not be a problem here. If the function is not intended to throw when used within its contract it can (should?) be noexcept. If it calls functions that may throw outside of the contract this is undefined behaviour anyway and the std::terminate implied by noexcept is reasonable.

Here, however, the documentation explicitly says that we either get a valid result or a null-reference. While the latter is a highly doubtful construct, it still says there is no case where an exception is expected.

Sorry, the discussion went into the commit. To sum up:

IMHO if there is a clearly defined documented "exceptional" but still valid use case where an exception is thrown, a function should clearly not be noexcept, because throwing is within its contract. If it should not throw within its contract noexcept is OK. Any exception thrown with the function is then either the consequence of undefined behaviour or a bug. In both cases calling std::terminate by not propagating the exception is very reasonable.

@markus.blatt: You assigned this to me. However, I hesitate to merge, because I don't use this code. I just highlighted the 'rules' that we should IMHO follow when deciding on noexcept. I guess you can decide better on the result of these 'rules' for this specific code.

Then I really do not see what noexcept buys us or the compiler. My assumption was that the compiler can do some optimization with noexcept but how can that work if it does not know the contract.

Contract here means, what we promise to the caller of the function. Obviously the compiler cannot know this. The noexcept keyword exists for telling it to the compiler. We can still throw inside of a noexcept function. But now the compiler knows that this means we leave the intended contract. Hence it will (optimization (A)) replace such a throw by a program termination and (optimization (B)) exploit that the caller does not need to deal with exceptions.

(A) may reduce code size while (B), e.g., allows to replace copies by move operations.

changed milestone to %DUNE 2.6.0

mentioned in commit 22d3a9df

merged

mentioned in commit 223a563f

mentioned in merge request !377 (merged)