@kloepper pointed out a while back that every compiler you've ever heard of supports this. Plus, it's more concise, it's not prone to copy-paste errors, and it looks nicer.

At the time I wanted to remain consistent and I didn't feel like spending the time to update all my existing code. But, every time I've added a new header since I've cursed the include guard, so I finally broke down and changed it.

Detected by -fsanitize=vla-bound

E.g.:

    "foo"_kj

This literal will have type StringPtr. Although any string literal can implicitly cast to StringPtr, using the _kj suffix has the advantage that it can be constexpr.

- Rename UtfResult -> EncodingResult
- Make it usable like a Maybe, so that we don't need separate "try" functions.
- Check errors in hex decoding and URI decoding.

This conversion would end up including the NUL terminator in the array, which is almost never what you want.

We can perhaps re-enable this in the future and have it automatically remove the NUL terminator, but we should do at least one release with it disabled to catch anyone who might be affected by the change in behavior.

VS2015 only barely compiled ~NullableValue's noexcept specifier
expression. VS2017 can't at all, so we're going with noexcept(false) for
MSVC for now.

Fixes #212

I'm not really sure how Cap'n Proto has worked at all on GCC 5. For some reason this only ended up being tickled after e6e29122.

Fixes #442.

Since this header is included by everyone, and units.h has lots of templates, this seems like it could significantly improve build times.

The problem with kj::range() is that if the inputs are not recognized as the same type, the typechecker can get annoyed.

MSVC refuses the following code:

struct Foo { Foo(Foo&) {} };
Foo foo;
[foo] {}();

because it only seems to want to consider const copy constructors when
capturing objects by value in lambda capture lists.

MSVC cannot compile the overloaded member function SFINAE technique used
in Kind_ and FromAny_. It has an easier time with std::void_t-style
SFINAE.

Fix JSON handler for DynamicStruct. The handler needs to be told the struct's schema to construct an orphan.

Also improve error message when addTypeHandler() is given a handler for a dynamic type but no specific schema is specified. We could support this eventually but we don't presently.

Maybe::emplace() should return the newly-constructed value so that you don't have to immediately KJ_ASSERT_NONNULL it.

- Reduce noise.
- Trace through async callbacks.

https://llvm.org/bugs/show_bug.cgi?id=22354

At the time DisallowConstCopy was introduced, GCC 4.7 and Clang 3.2 refused to allow the non-const copy constructors to be defaulted inline. This must have been concluded to be a compiler bug, as GCC 4.8 and Clang 3.4 seem fine with it. So, we can clean this up.

Meanwhile, the above-linked Clang bug triggered when a DisallowConstCopy derivative is captured by value in a C++14 generic lambda. capnp::CallContext in particular tended to be hit by this a lot. The bug only affects non-default (or out-of-line default) copy constructors, and thus is conveniently sidestepped by this change.