Issue Details

Number: 24423
Title: Add `not_null<T>` from the Guidelines Support Library
Description: There are many places in the codebase where we use a pointer type (`*`, `shared_ptr`, `unique_ptr`, etc.) because of historical reasons (`CBlockIndex*`) or for polymorphism. In many such cases, we may want to avoid needing to handle the pointer being null, or make it clear in the function contract that we require a non-null pointer. `not_null<T>` is the solution proposed by the C++ Core Guidelines ([relevant section](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-nullptr)), and restricts pointers and smart pointers to hold non-null values. Since I've learned about this, I've repeatedly ran into scenarios where I wish I could use it so as to make call semantics clearer and avoid misuse / unnecessary null handling. ----- There is a header-only implementation of `not_null<T>` [here](https://github.com/microsoft/GSL/blob/4377f6e603c64a86c934f1546aa9db482f2e1a4e/include/gsl/pointers#L69-L82), however, there are two issues we need to solve: 1. The header-only implementation linked above requires the `Expects` and `Ensures` macros defined [here](https://github.com/microsoft/GSL/blob/4377f6e603c64a86c934f1546aa9db482f2e1a4e/include/gsl/assert#L129-L130), do we also import these or can we tweak our existing assertion macros to work? 2. There is also a [`strict_not_null<T>`](https://github.com/microsoft/GSL/blob/4377f6e603c64a86c934f1546aa9db482f2e1a4e/include/gsl/pointers#L222-L238), which requires explicit construction. Do we need that or just `not_null<T>`?
URL: https://github.com/bitcoin/bitcoin/issue/24423
Closed by

Back to List