# TL;DR for #CppSan
This article is a brief introduction to works mentioned in https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/.

## The One Range Proposal was merged
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0896r3.pdf

See https://en.cppreference.com/w/cpp/experimental/ranges

#include <ranges>
using namespace std::ranges;
vector<int> ints{0,1,2,3,4,5};
auto even = [](int i){ return 0 == i % 2; };
auto square = [](int i) { return i * i; };
for (int i : ints | view::filter(even) | view::transform(square)) {
cout << i << ’ ’; // prints: 0 4 16
}
for (int i : iota_view{1, 10})
    cout << i << ’ ’; // prints: 1 2 3 4 5 6 7 8 9****

string str{"the quick brown fox"};
split_view sentence{str, ’ ’};
for (auto word : sentence) {
    for (char ch : word)
        cout << ch;
    cout << " *";
}
// The above prints: the *quick *brown *fox *

// Existing functions in <algorithm> add support
// for Ranges
// Existing one:
template<class InputIterator, class OutputIterator,
class UnaryOperation>
constexpr OutputIterator
transform(InputIterator first1, InputIterator last1,
OutputIterator result, UnaryOperation op);
// The new ones:
constexpr unary_transform_result<I, O>
transform(I first1, S last1, O result, F op, Proj proj = Proj{});
// S = Sentinel<I>=
constexpr unary_transform_result<safe_iterator_t<Rng>, O>
transform(Rng&& rng, O result, F op, Proj proj = Proj{});
// Roughly equivalent to
// for (auto& v: rng)
//    *result++ = F(proj(v));
// By default, Proj = Identity

## Constrained auto
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1141r1.html

Before this, Concept can only be used in template type arguments. Now it can be used in parameter/return types.

void f(Sortable auto x); // can't omit "auto" here
Sortable g(); // auto omitted, = Sortable auto g()
Sortable x = g(); // = Sortable auto x = g();

## consteval function
> https://wg21.link/P1073

The problem: `constexpr` cannot guarantee the computation always happens at compile time

constexpr int f(int y);
constexpr int x = f(100); // OK, guaranteed compile-time computation
int y = 100;
int z = f(y); // Not guaranteed

Now we can use `constval` to enforce compile-time computation. If it can't be done at compile time, an error will be raised.

consteval int sqrsqr(int n) {
  return sqr(sqr(n)); // Not a constant-expression at this  point,
}                     // but that's okay.

## std::is_constant_evaluated
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0595r1.html

constexpr Regex compile_regex(string_view sv)
{
    if (std::is_constant_evaluated())
        return CompileTimeCompiledRegex(sv);
    else
        return RuntimeCompiledRegex(sv); // may require heap alloc
}

## Constexpr union
> https://github.com/ldionne/wg21/blob/master/generated/p1330r0.pdf

This proposal allows modifcation of active member in a union.

union Foo {
    int i;
    float f;
};

constexpr int use() {
    Foo foo{};
    foo.i = 3;
    foo.f = 1.2f; // valid now
    return 1;
}

static_assert(use());

## Constexpr try and catch
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1002r0.pdf

Reason: must allow `try/catch` block in constexpr function (e.g., `std::vector::insert`), but current standard prohibits it.

When evaluated in constant expression, an executed `throw` in `constexpr` function will raise a compile error.

constexpr int f(int x) {
    try { return x + 1; } // ERROR: can’t appear in constexpr function, Now permitted
    catch (...) { return 0; }
}

## constexpr dynamic_cast and typeid
> [Link: Missing]: 404

Virtual function call in constant expression has already been allowed in the last meeting, now it comes to `dynamic_cast` and `typeid`

constexpr Derived a;
constexpr Base* p = &a;

constexpr int f(Base* p) {
    if (dynamic_cast<Derived*>(p)) {
        // ...
     } else {
        // ...
     }
}

constexpr result = f(p);

## Constexpr std::pointer_traits

> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1006r1.pdf

## Misc constexpr bits
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1032r1.html

A bunch of small modifications:
- `std::pair/tuple`: `piecewise_construct` constructor，`operator =`, `swap`
- `std::array/array_view`: `swap`
- `char_traits`: `move`, `copy`, `assign`
- ` string_view`: `copy`
- `insert_iterator` and many other iterators: `=`, `*`, `++`

## Revised Memory Model
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0668r4.html

- Existing implementation schemes on Power and ARM are not correct with respect to the current memory model definition. These implementation schemes can lead to results that are disallowed by the current memory model when the user combines acquire/release ordering with seq_cst ordering. On some architectures, especially Power and Nvidia GPUs, it is expensive to repair the implementations to satisfy the existing memory model. Details are discussed in (Lahav et al) http://plv.mpi-sws.org/scfix/paper.pdf (which this discussion relies on heavily). The same issues were briefly outlined at the Kona SG1 meeting. We summarize below.
- Our current definition of memory_order_seq_cst, especially for fences, is too weak. This was caused by historical assumptions that have since been disproved.
- The current definition of release sequence is problematic, allowing seemingly irrelevant memory_order_relaxed operations to interfere with synchronizes-with relationships.
- We still do not have an acceptable way to make our informal (since C++14) prohibition of out-of-thin-air results precise. The primary practical effect of that is that formal verification of C++ programs using relaxed atomics remains unfeasible. The above paper suggests a solution similar to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3710.html . We continue to ignore the problem here, but try to stay out of the way of such a solution. [0]
- The current definition of memory_order_consume is widely acknowledged to be unusable, and implementations generally treat it as memory_order_acquire. The current draft "temporarily discourages" it. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r1.html . There are proposals to repair it (cf. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r3.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0462r1.pdf ), but nothing that is ready to go.

[0]: Tl;dr for *out of thin air* result

Assume x and y are both initialized as 0:

Thread 1:
  r1 = x.load(memory_order_relaxed);
  y.store(r1, memory_order_relaxed);

Thread 2:
  r2 = y.load(memory_order_relaxed);
  x.store(r2, memory_order_relaxed);

This famously allows both r1 and r2 to have final values of 42, or any other "out of thin air" value. This occurs if each load sees the store in the other thread. It effectively models an execution in which the compiler speculates that both atomic variables will have a value of 42, speculatively stores the resulting values, and then performs the loads to confirm that the speculation was correct and nothing needs to be undone.

No known implementations actually produce such results. However, it is extraordinarily hard to write specifications that present them without also preventing legitimate compiler and hardware optimizations. As a first indication of the complexity, note that the following variation of the preceding example should ideally allow x = y = 42, and some existing implementations can produce such a result:

Thread 1:
  r1 = x.load(memory_order_relaxed);
  y.store(r1, memory_order_relaxed);

Thread 2:
  r2 = y.load(memory_order_relaxed);
  x.store(42, memory_order_relaxed);

## Signed integers are two's complement
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r0.html
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html

- Status-quo Signed integer arithmetic remains non-commutative in general (though some implementations may guarantee that it is).
- Change bool is represented as 0 for false and 1 for true. All other representations are undefined.
- Change bool only has value bits, no padding bits.
- Change Signed integers are two’s complement.
- Change If there are M value bits in the signed type and N in the unsigned type, then M = N-1 (whereas C says M ≤ N).
- etc (Read the paper for more)

## char8_t: A type for UTF-8 characters and strings
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0482r5.html

The base type of `u8` char/string literals is changed to `char8_t`, which is basically the same as `unsigned char`, but does not alias with any other type.

char ca[] = u8"text";   // C++17: Ok.
                        // This proposal: Ill-formed.

char8_t c8a[] = "text"; // C++17: N/A (char8_t is not a type specifier).
                        // This proposal: Ill-formed.

## Nested Inline Namespaces
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1094r1.html

namespace std::experimental::inline parallelism_v2::execution {
    // ...
}
// equivalent to
namespace std::experimental {
inline namespace parallelism_v2 {
namespace execution {
   // ...
}
}
}

## std::assume_aligned
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf

A unification of existing compiler-specific intrinsic:
- GCC: `__builtin_assume_aligned(const void* ptr, size_t N)`
- MSVC`__assume(expr)`
- OpenMP: `#pragma omp simd aligned`

for better vectorized code

void mult(float* x, int size, float factor)
{
    float* ax = std::assume_aligned<64>(x); // we promise that x is aligned to 64 bytes
    for (int i = 0; i < size; ++i) // loop will be optimised accordingly
    ax[i] *= factor;
}