The ArrayLike type concept focuses on array-like data accesses. This
means the ability to randomly index, obtain size information, as well as
being able to expose the storage pointer. The last two already have the
standard APIs `size` and `data`, respectively.
The ArrayLike concept should always be fulfilled by Vector, FixedArray
and Array as the three main array-like types. C-style arrays themselves
of course can't fulfil ArrayLike (which could be considered ironic), but
as we don't use them much anyways this isn't a problem.
This concept describes a type with a begin()/end() pair that can
function as an iterator, given the following criteria:
- The return type of begin() is comparable with the return type of
end(), and the comparison (with operator!=) yields a bool
- The object returned from begin() can be pre-incremented
- The iterator has an operator*() implementation
By constraining two implementations, the compiler will select the best
fitting one. All this will require is duplicating the implementation and
simplifying for the `void` case.
This constraining also informs both the caller and compiler by passing
the callback parameter types as part of the constraint
(e.g.: `IterationFunction<int>`).
Some `for_each` functions in LibELF only take functions which return
`void`. This is a minimal correctness check, as it removes one way for a
function to incompletely do something.
There seems to be a possible idiom where inside a lambda, a `return;` is
the same as `continue;` in a for-loop.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
This commit makes the user-facing StdLibExtras templates and utilities
arguably more nice-looking by removing the need to reach into the
wrapper structs generated by them to get the value/type needed.
The C++ standard library had to invent `_v` and `_t` variants (likely
because of backwards compat), but we don't need to cater to any codebase
except our own, so might as well have good things for free. :^)
The Coverity compiler doesn't support C++2a yet, and thus doesn't
even recognize concept keywords. To allow serenity to be built and
analyzed on such compilers, add a fallback underdef to perform
the same template restriction based on AK::EnableIf<..> meta
programming.
Note: Coverity does seem to (annoyingly) define __cpp_concepts, even
though it doesn't support them, so we need to further check for
__COVERITY__ explicitly.
