system/serenity
system/serenity
1
0
Fork 0
mirror of https://github.com/SerenityOS/serenity synced 2024-11-05 17:46:52 +00:00
Code Issues Projects Releases Packages Wiki Activity
serenity/AK/Concepts.h

188 lines
4.2 KiB
C
Raw Normal View History

AK: Add Integral and FloatingPoint concepts.
2020-08-03 18:14:37 +00:00
/*
* Copyright (c) 2020, the SerenityOS developers.
*
Everything: Move to SPDX license identifiers in all files. 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 *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
AK: Add Integral and FloatingPoint concepts.
2020-08-03 18:14:37 +00:00
*/
#pragma once
AK: Add a Concept for any String type
2021-11-07 13:40:10 +00:00
#include <AK/Forward.h>
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
#include <AK/IterationDecision.h>
AK: Add Integral and FloatingPoint concepts.
2020-08-03 18:14:37 +00:00
#include <AK/StdLibExtras.h>
namespace AK::Concepts {
template<typename T>
AK+Everywhere: Make StdLibExtras templates less wrapper-y 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. :^)
2021-04-10 13:59:06 +00:00
concept Integral = IsIntegral<T>;
AK: Add Integral and FloatingPoint concepts.
2020-08-03 18:14:37 +00:00
template<typename T>
AK+Everywhere: Make StdLibExtras templates less wrapper-y 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. :^)
2021-04-10 13:59:06 +00:00
concept FloatingPoint = IsFloatingPoint<T>;
AK: Add Integral and FloatingPoint concepts.
2020-08-03 18:14:37 +00:00
AK: Add the Fundamental concept
2022-02-22 21:04:24 +00:00
template<typename T>
concept Fundamental = IsFundamental<T>;
AK: Add complex number library Useful for diverse algorithms. Also added some tests for it.
2021-03-19 21:23:48 +00:00
template<typename T>
AK+Everywhere: Make StdLibExtras templates less wrapper-y 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. :^)
2021-04-10 13:59:06 +00:00
concept Arithmetic = IsArithmetic<T>;
AK: Add complex number library Useful for diverse algorithms. Also added some tests for it.
2021-03-19 21:23:48 +00:00
AK: Add Signed/Unsigned concepts.
2021-03-27 21:20:15 +00:00
template<typename T>
AK+Everywhere: Make StdLibExtras templates less wrapper-y 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. :^)
2021-04-10 13:59:06 +00:00
concept Signed = IsSigned<T>;
AK: Add Signed/Unsigned concepts.
2021-03-27 21:20:15 +00:00
template<typename T>
AK+Everywhere: Make StdLibExtras templates less wrapper-y 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. :^)
2021-04-10 13:59:06 +00:00
concept Unsigned = IsUnsigned<T>;
AK: Add Signed/Unsigned concepts.
2021-03-27 21:20:15 +00:00
AK+LibIPC: Make all enums codable If an enum has a supported underlying type we can provide encoding and decoding for the enum as well.
2021-07-04 04:44:34 +00:00
template<typename T>
concept Enum = IsEnum<T>;
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
template<typename T, typename U>
concept SameAs = IsSame<T, U>;
AK: Add the `ConvertibleTo` concept
2023-01-19 01:29:39 +00:00
template<class From, class To>
concept ConvertibleTo = IsConvertible<From, To>;
AK: Add a 'OneOf' concept Similar to 'SameAs', but for multiple types.
2022-03-28 11:52:00 +00:00
template<typename U, typename... Ts>
concept OneOf = IsOneOf<U, Ts...>;
AK: Add a OneOfIgnoringCV concept Some functions want to ignore cv-qualifiers, and it's much easier to constrain the type through a concept than a separate requires clause on the function.
2022-04-17 04:51:55 +00:00
template<typename U, typename... Ts>
concept OneOfIgnoringCV = IsOneOfIgnoringCV<U, Ts...>;
AK: Add a 'SpecializationOf' concept The counterpart to the IsSpecializationOf<...> template.
2022-02-14 13:18:51 +00:00
template<typename T, template<typename...> typename S>
concept SpecializationOf = IsSpecializationOf<T, S>;
AK: Introduce the `DerivedFrom` concept
2022-12-06 22:02:58 +00:00
template<typename T, typename S>
concept DerivedFrom = IsBaseOf<S, T>;
AK: Add a Concept for any String type
2021-11-07 13:40:10 +00:00
template<typename T>
AK: Ensure string types are actually considered hash-compatible The AnyString concept is currently broken because it checks whether a StringView is constructible from a type T. The StringView constructors, however, only accept constant rvalue references - i.e. `T const&`. This also adds a test to ensure this continues to work.
2023-02-02 15:48:11 +00:00
concept AnyString = IsConstructible<StringView, RemoveCVReference<T> const&>;
AK: Add a Concept for any String type
2021-11-07 13:40:10 +00:00
AK: Add the concept of hash-compatible types
2021-11-07 13:50:41 +00:00
template<typename T, typename U>
concept HashCompatible = IsHashCompatible<Detail::Decay<T>, Detail::Decay<U>>;
AK: Introduce the ArrayLike concept 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.
2022-01-27 11:53:52 +00:00
// Any indexable, sized, contiguous data structure.
template<typename ArrayT, typename ContainedT, typename SizeT = size_t>
Everywhere: Remove 'clang-format off' comments that are no longer needed
2023-07-08 02:59:01 +00:00
concept ArrayLike = requires(ArrayT array, SizeT index) {
AK: Introduce the ArrayLike concept 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.
2022-01-27 11:53:52 +00:00
{
array[index]
}
-> SameAs<RemoveReference<ContainedT>&>;
{
array.size()
}
-> SameAs<SizeT>;
{
array.span()
}
-> SameAs<Span<RemoveReference<ContainedT>>>;
{
array.data()
}
-> SameAs<RemoveReference<ContainedT>*>;
};
AK: Introduce Indexable concept This was dearly missing and can be used in many existing templates.
2022-04-21 08:41:27 +00:00
// Any indexable data structure.
template<typename ArrayT, typename ContainedT, typename SizeT = size_t>
Everywhere: Remove 'clang-format off' comments that are no longer needed
2023-07-08 02:59:01 +00:00
concept Indexable = requires(ArrayT array, SizeT index) {
AK: Introduce Indexable concept This was dearly missing and can be used in many existing templates.
2022-04-21 08:41:27 +00:00
{
array[index]
}
-> OneOf<RemoveReference<ContainedT>&, RemoveReference<ContainedT>>;
};
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
template<typename Func, typename... Args>
Everywhere: Remove 'clang-format off' comments that are no longer needed
2023-07-08 02:59:01 +00:00
concept VoidFunction = requires(Func func, Args... args) {
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
{
func(args...)
}
AK: Make C++ concepts support mandatory for compilers The latest GCC and Clang versions both support this, so we can freely use these in our code.
2021-06-19 11:13:31 +00:00
-> SameAs<void>;
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
};
template<typename Func, typename... Args>
Everywhere: Remove 'clang-format off' comments that are no longer needed
2023-07-08 02:59:01 +00:00
concept IteratorFunction = requires(Func func, Args... args) {
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
{
func(args...)
}
AK: Make C++ concepts support mandatory for compilers The latest GCC and Clang versions both support this, so we can freely use these in our code.
2021-06-19 11:13:31 +00:00
-> SameAs<IterationDecision>;
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
};
AK: Add a concept for iterable containers 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
2021-07-22 14:37:17 +00:00
template<typename T, typename EndT>
Everywhere: Remove 'clang-format off' comments that are no longer needed
2023-07-08 02:59:01 +00:00
concept IteratorPairWith = requires(T it, EndT end) {
AK: Add a concept for iterable containers 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
2021-07-22 14:37:17 +00:00
*it;
Everywhere: Remove 'clang-format off' comments that are no longer needed
2023-07-08 02:59:01 +00:00
{
it != end
} -> SameAs<bool>;
AK: Add a concept for iterable containers 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
2021-07-22 14:37:17 +00:00
++it;
};
template<typename T>
Everywhere: Remove 'clang-format off' comments that are no longer needed
2023-07-08 02:59:01 +00:00
concept IterableContainer = requires {
{
declval<T>().begin()
} -> IteratorPairWith<decltype(declval<T>().end())>;
AK: Add a concept for iterable containers 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
2021-07-22 14:37:17 +00:00
};
AK: Add a concept for requiring that a function is fallible This ensures that the function may be wrapped with TRY() and MUST().
2022-11-17 12:52:39 +00:00
template<typename Func, typename... Args>
concept FallibleFunction = requires(Func&& func, Args&&... args) {
func(forward<Args>(args)...).is_error();
func(forward<Args>(args)...).release_error();
func(forward<Args>(args)...).release_value();
};
AK: Add a CallableAs<R, Args...> concept This is just the concept version of the IsCallableWithArguments type trait previously defined in Function.h.
2023-07-08 10:38:25 +00:00
}
namespace AK::Detail {
template<typename T, typename Out, typename... Args>
inline constexpr bool IsCallableWithArguments = requires(T t) {
{
t(declval<Args>()...)
} -> Concepts::ConvertibleTo<Out>;
} || requires(T t) {
{
t(declval<Args>()...)
} -> Concepts::SameAs<Out>;
};
}
namespace AK {
using Detail::IsCallableWithArguments;
}
namespace AK::Concepts {
template<typename Func, typename R, typename... Args>
concept CallableAs = Detail::IsCallableWithArguments<Func, R, Args...>;
AK: Add Integral and FloatingPoint concepts.
2020-08-03 18:14:37 +00:00
}
AK: Pull Is{Integral,FloatingPoint} into the global namespace
2020-12-05 22:25:19 +00:00
AK: Export Details and Concepts into the AK namespace AK internals like to use concepts and details without a fully qualified name, which usually works just fine because we make everything AK-related available to the unqualified namespace. However, this breaks as soon as we start not using `USING_AK_GLOBALLY`, due to those identifiers no longer being made available. Instead, we just export those into the `AK` namespace instead.
2022-11-27 15:35:35 +00:00
#if !USING_AK_GLOBALLY
namespace AK {
#endif
AK: Make Concepts.h and StdLibExtras.h properly alias their own sumbols.
2021-03-27 21:24:50 +00:00
using AK::Concepts::Arithmetic;
AK: Introduce the ArrayLike concept 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.
2022-01-27 11:53:52 +00:00
using AK::Concepts::ArrayLike;
AK: Add a CallableAs<R, Args...> concept This is just the concept version of the IsCallableWithArguments type trait previously defined in Function.h.
2023-07-08 10:38:25 +00:00
using AK::Concepts::CallableAs;
AK: Add the `ConvertibleTo` concept
2023-01-19 01:29:39 +00:00
using AK::Concepts::ConvertibleTo;
AK: Introduce the `DerivedFrom` concept
2022-12-06 22:02:58 +00:00
using AK::Concepts::DerivedFrom;
AK+LibIPC: Make all enums codable If an enum has a supported underlying type we can provide encoding and decoding for the enum as well.
2021-07-04 04:44:34 +00:00
using AK::Concepts::Enum;
AK: Add a concept for requiring that a function is fallible This ensures that the function may be wrapped with TRY() and MUST().
2022-11-17 12:52:39 +00:00
using AK::Concepts::FallibleFunction;
AK: Make Concepts.h and StdLibExtras.h properly alias their own sumbols.
2021-03-27 21:24:50 +00:00
using AK::Concepts::FloatingPoint;
AK: Add the Fundamental concept
2022-02-22 21:04:24 +00:00
using AK::Concepts::Fundamental;
AK: Introduce Indexable concept This was dearly missing and can be used in many existing templates.
2022-04-21 08:41:27 +00:00
using AK::Concepts::Indexable;
AK: Make Concepts.h and StdLibExtras.h properly alias their own sumbols.
2021-03-27 21:24:50 +00:00
using AK::Concepts::Integral;
AK: Add a concept for iterable containers 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
2021-07-22 14:37:17 +00:00
using AK::Concepts::IterableContainer;
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
using AK::Concepts::IteratorFunction;
AK: Add a concept for iterable containers 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
2021-07-22 14:37:17 +00:00
using AK::Concepts::IteratorPairWith;
AK: Add a 'OneOf' concept Similar to 'SameAs', but for multiple types.
2022-03-28 11:52:00 +00:00
using AK::Concepts::OneOf;
AK: Add a OneOfIgnoringCV concept Some functions want to ignore cv-qualifiers, and it's much easier to constrain the type through a concept than a separate requires clause on the function.
2022-04-17 04:51:55 +00:00
using AK::Concepts::OneOfIgnoringCV;
AK: Export the SameAs concept
2022-01-27 12:44:53 +00:00
using AK::Concepts::SameAs;
AK: Add Signed/Unsigned concepts.
2021-03-27 21:20:15 +00:00
using AK::Concepts::Signed;
AK: Add a 'SpecializationOf' concept The counterpart to the IsSpecializationOf<...> template.
2022-02-14 13:18:51 +00:00
using AK::Concepts::SpecializationOf;
AK: Add Signed/Unsigned concepts.
2021-03-27 21:20:15 +00:00
using AK::Concepts::Unsigned;
AK+Kernel+LibELF: Remove the need for `IteratorDecision::Continue` 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.
2021-05-16 09:36:52 +00:00
using AK::Concepts::VoidFunction;
AK: Export Details and Concepts into the AK namespace AK internals like to use concepts and details without a fully qualified name, which usually works just fine because we make everything AK-related available to the unqualified namespace. However, this breaks as soon as we start not using `USING_AK_GLOBALLY`, due to those identifiers no longer being made available. Instead, we just export those into the `AK` namespace instead.
2022-11-27 15:35:35 +00:00
#if !USING_AK_GLOBALLY
}
AK: Make it possible to not `using` AK classes into the global namespace This patch adds the `USING_AK_GLOBALLY` macro which is enabled by default, but can be overridden by build flags. This is a step towards integrating Jakt and AK types.
2022-11-26 11:18:30 +00:00
#endif
Reference in a new issue Copy permalink