Concept to separate safety critical API from non critical.

[elfenpiff]

Brief feature description

Some containers and classes may have an API which should avoided in a safety critical context since it can cause mistakes and bugs easily.

Examples could be:

myOptional.value(); // can crash if optional does not contain a value
myVector[123]; // can crash if vector has a size of `<=123`.

We should provide an alternative API which performs the same task like for instance:

auto optionalValue = myOptional.value_or(123);
myOptional.and_then([](auto & value){ /*...*/});

myVector.for(123, [](auto & value){ /* ... */ });

And separate the unsafe API from the safe API like for instance

class vector {
  public:
    void safeApiCall();
}

 // extend the interface of the vector but do not add additional members, or overload methods
class unsafe_vector : public vector {
  public:
    using vector::vector;
    void unsafeApiCall();
}

ToDo

• [ ] Write design document howto separate unsafe API from safe API
• [ ] Identify classes where methods with the wrong parameters can cause a call to the errorHandler, std::terminate, undefined behavior or a crash.
• [ ] Add additional API with the same functionality to the identified classes which is unable to crash or lead to undefined behavior.