beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 15:40:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/AK/Concepts.h

133 lines
2.8 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 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: Add a Concept for any String type
2021-11-07 13:40:10 +00:00
template<typename T>
concept AnyString = Detail::IsConstructible<StringView, T>;
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: 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
// FIXME: remove once Clang formats these properly.
// clang-format off
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>
concept ArrayLike = requires(ArrayT array, SizeT index)
{
{
array[index]
}
-> SameAs<RemoveReference<ContainedT>&>;
{
array.size()
}
-> SameAs<SizeT>;
{
array.span()
}
-> SameAs<Span<RemoveReference<ContainedT>>>;
{
array.data()
}
-> SameAs<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>
concept VoidFunction = requires(Func func, Args... args)
{
{
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>
concept IteratorFunction = requires(Func func, Args... args)
{
{
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>
concept IteratorPairWith = requires(T it, EndT end)
{
*it;
{ it != end } -> SameAs<bool>;
++it;
};
template<typename T>
concept IterableContainer = requires
{
{ declval<T>().begin() } -> IteratorPairWith<decltype(declval<T>().end())>;
};
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
// clang-format on
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: 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+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: 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: 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;
Reference in a new issue Copy permalink