Add optional_lookup utility function

[hannes-steffenhagen-diffblue]

This provides a more ergonomic interface over map::find for the case when you don't need an iterator

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[xbauch]

Looks good, would be nice to generalise it to use std::find in the general case. Then a specialisation for containers that implement their own find function.

[hannes-steffenhagen-diffblue]

@xbauch Thought about it, wasn't completely sure if it was a good idea because for most containers the result should be optional<value_type>, except for map where we only want the value but value_type is a key-value pair... Could certainly implement it like that, just worried that it might be confusing.

[allredj]

✔️
Passed Diffblue compatibility checks (cbmc commit: 5139616).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/92738933

[sonodtt]

Interesting. To follow on from @xbauch 's comment - it seems that as a generic problem, this becomes quite non-trivial.
As I understand it, specialisation in the generic scenario "has a method .find()" would involve the member detection idiom. Can define a trait for checking for find(). Quite an issue to make robust considering inherited methods et al.
But essentially a form of contract.

In the non generic scenairo an overload for std::map or other known types.

These guys, who quite definitely know what they're doing - found a simple edge case, that seemed surprisingly hard to get right:
https://web.archive.org/web/20180409123554/https://blog.quasardb.net/sfinae-hell-detecting-template-methods

[tautschnig]

This strictly needs a unit test. At present, we don't even know whether this is syntactically acceptable to all our compilers used in CI.

[tautschnig]

Why are those includes required here?

[hannes-steffenhagen-diffblue]

@tautschnig Removed vestigial includes and added a unit test

[allredj]

✔️
Passed Diffblue compatibility checks (cbmc commit: 4e506bc).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/93002859

[hannes-steffenhagen-diffblue]

CodeBuild failure due to spurious network issues, restarting CI

[allredj]

✔️
Passed Diffblue compatibility checks (cbmc commit: fa39d19).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/93043043