react-native-windows 0.83.0 → 0.83.3

package/external/folly/folly/docs/FBString.md

@@ -0,0 +1,46 @@
+`folly/FBString.h`
+------------------
+
+`fbstring` is a drop-in replacement for `std::string`. The main
+benefit of `fbstring` is significantly increased performance on
+virtually all important primitives. This is achieved by using a
+three-tiered storage strategy and by cooperating with the memory
+allocator. In particular, `fbstring` is designed to detect use of
+jemalloc and cooperate with it to achieve significant improvements in
+speed and memory usage.
+
+`fbstring` supports 32- and 64-bit and little- and big-endian
+architectures.
+
+### Storage strategies
+***
+
+* Small strings (<= 23 chars) are stored in-situ without memory
+  allocation.
+
+* Medium strings (24 - 255 chars) are stored in malloc-allocated
+  memory and copied eagerly.
+
+* Large strings (> 255 chars) are stored in malloc-allocated memory and
+  copied lazily.
+
+### Implementation highlights
+***
+
+* 100% compatible with `std::string`.
+
+* Thread-safe reference counted copy-on-write for "large"
+  strings (> 255 chars).
+
+* Uses `malloc` instead of allocators.
+
+* Jemalloc-friendly. `fbstring` automatically detects if application
+  uses jemalloc and if so, significantly improves allocation
+  strategy by using non-standard jemalloc extensions.
+
+* `find()` is implemented using simplified Boyer-Moore
+  algorithm. Casual tests indicate a 30x speed improvement over
+  `string::find()` for successful searches and a 1.5x speed
+  improvement for failed searches.
+
+* Offers conversions to and from `std::string`.

package/external/folly/folly/docs/FBVector.md

@@ -0,0 +1,200 @@
+`folly/FBVector.h`
+------------------
+
+Simply replacing `std::vector` with `folly::fbvector` (after
+having included the `folly/FBVector.h` header file) will
+improve the performance of your C++ code using vectors with
+common coding patterns. The improvements are always non-negative,
+almost always measurable, frequently significant, sometimes
+dramatic, and occasionally spectacular.
+
+### Sample
+***
+```cpp
+    folly::fbvector<int> numbers({0, 1, 2, 3});
+    numbers.reserve(10);
+    for (int i = 4; i < 10; i++) {
+      numbers.push_back(i * 2);
+    }
+    assert(numbers[6] == 12);
+```
+### Motivation
+***
+
+`std::vector` is the stalwart abstraction many use for
+dynamically-allocated arrays in C++. It is also the best known
+and most used of all containers. It may therefore seem a
+surprise that `std::vector` leaves important - and sometimes
+vital - efficiency opportunities on the table. This document
+explains how our own drop-in abstraction `fbvector` improves key
+performance aspects of `std::vector`. Refer to
+folly/test/FBVectorTest.cpp for a few benchmarks.
+
+### Memory Handling
+***
+
+It is well known that `std::vector` grows exponentially (at a
+constant factor) in order to avoid quadratic growth performance.
+The trick is choosing a good factor. Any factor greater than 1
+ensures O(1) amortized append complexity towards infinity. But a
+factor that's too small (say, 1.1) causes frequent vector reallocation, and
+one that's too large (say, 3 or 4) forces the vector to consume much more
+memory than needed.
+
+The initial HP implementation by Stepanov used a
+growth factor of 2; i.e., whenever you'd `push_back` into a vector
+without there being room, it would double the current capacity. This
+was not a good choice: it can be mathematically proven that a growth factor of
+2 is rigorously the <i>worst</i> possible because it never allows the vector 
+to reuse any of its previously-allocated memory. Despite other compilers
+reducing the growth factor to 1.5, gcc has staunchly maintained its factor of
+2. This makes `std::vector` cache- unfriendly and memory manager unfriendly.
+
+To see why that's the case, consider a large vector of capacity C.
+When there's a request to grow the vector, the vector
+(assuming no in-place resizing, see the appropriate section in
+this document) will allocate a chunk of memory next to its current chunk,
+copy its existing data to the new chunk, and then deallocate the old chunk.
+So now we have a chunk of size C followed by a chunk of size k * C. Continuing
+this process we'll then have a chunk of size k * k * C to the right and so on.
+That leads to a series of the form (using ^^ for power):
+
+    C, C*k,  C*k^^2, C*k^^3, ...
+
+If we choose k = 2 we know that every element in the series will
+be strictly larger than the sum of all previous ones because of
+the remarkable equality:
+
+    1 + 2^^1 + 2^^2 + 2^^3... + 2^^n = 2^^(n+1) - 1
+
+This means that any new chunk requested will be larger
+than all previously used chunks combined, so the vector must
+crawl forward in memory; it can't move back to its deallocated chunks.
+But any number smaller than 2 guarantees that you'll at some point be 
+able to reuse the previous chunks. For instance, choosing 1.5 as the factor
+allows memory reuse after 4 reallocations; 1.45 allows memory reuse after 3
+reallocations; and 1.3 allows reuse after only 2 reallocations.
+
+Of course, the above makes a number of simplifying assumptions
+about how the memory allocator works, but definitely you don't
+want to choose the theoretically absolute worst growth factor.
+`fbvector` uses a growth factor of 1.5. That does not impede good
+performance at small sizes because of the way `fbvector`
+cooperates with jemalloc (below).
+
+### The jemalloc Connection
+***
+
+Virtually all modern allocators allocate memory in fixed-size
+quanta that are chosen to minimize management overhead while at
+the same time offering good coverage at low slack. For example, an
+allocator may choose blocks of doubling size (32, 64, 128,
+<t_co>, ...) up to 4096, and then blocks of size multiples of a
+page up until 1MB, and then 512KB increments and so on.
+
+As discussed above, `std::vector` also needs to (re)allocate in
+quanta. The next quantum is usually defined in terms of the
+current size times the infamous growth constant. Because of this
+setup, `std::vector` has some slack memory at the end much like
+an allocated block has some slack memory at the end.
+
+It doesn't take a rocket surgeon to figure out that an allocator-
+aware `std::vector` would be a marriage made in heaven: the
+vector could directly request blocks of "perfect" size from the
+allocator so there would be virtually no slack in the allocator.
+Also, the entire growth strategy could be adjusted to work
+perfectly with allocator's own block growth strategy. That's
+exactly what `fbvector` does - it automatically detects the use
+of jemalloc and adjusts its reallocation strategy accordingly.
+
+But wait, there's more. Many memory allocators do not support in-
+place reallocation, although most of them could. This comes from
+the now notorious design of `realloc()` to opaquely perform
+either in-place reallocation or an allocate-memcpy-deallocate
+cycle. Such lack of control subsequently forced all clib-based
+allocator designs to avoid in-place reallocation, and that
+includes C++'s `new` and `std::allocator`. This is a major loss of
+efficiency because an in-place reallocation, being very cheap,
+may mean a much less aggressive growth strategy. In turn that
+means less slack memory and faster reallocations.
+
+### Object Relocation
+***
+
+One particularly sensitive topic about handling C++ values is
+that they are all conservatively considered <i>non-
+relocatable</i>. In contrast, a relocatable value would preserve
+its invariant even if its bits were moved arbitrarily in memory.
+For example, an `int32_t` is relocatable because moving its 4 bytes
+would preserve its actual value, so the address of that value
+does not "matter" to its integrity.
+
+C++'s assumption of non-relocatable values hurts everybody for
+the benefit of a few questionable designs. The issue is that
+moving a C++ object "by the book" entails (a) creating a new copy
+from the existing value; (b) destroying the old value. This is
+quite vexing and violates common sense; consider this
+hypothetical conversation between Captain Picard and an
+incredulous alien:
+
+Incredulous Alien: "So, this teleporter, how does it work?"<br>
+Picard: "It beams people and arbitrary matter from one place to
+another."<br> Incredulous Alien: "Hmmm... is it safe?"<br>
+Picard: "Yes, but earlier models were a hassle. They'd clone the
+person to another location. Then the teleporting chief would have
+to shoot the original. Ask O'Brien, he was an intern during those
+times. A bloody mess, that's what it was."
+
+Only a tiny minority of objects are genuinely non-relocatable:
+
+* Objects that use internal pointers, e.g.:
+```cpp
+    class Ew {
+      char buffer[1024];
+      char * pointerInsideBuffer;
+    public:
+      Ew() : pointerInsideBuffer(buffer) {}
+      ...
+    }
+```
+* Objects that need to update "observers" that store pointers to them.
+
+The first class of designs can always be redone at small or no
+cost in efficiency. The second class of objects should not be
+values in the first place - they should be allocated with `new`
+and manipulated using (smart) pointers. It is highly unusual for
+a value to have observers that alias pointers to it.
+
+Relocatable objects are of high interest to `std::vector` because
+such knowledge makes insertion into the vector and vector
+reallocation considerably faster: instead of going to Picard's
+copy-destroy cycle, relocatable objects can be moved around
+simply by using `memcpy` or `memmove`. This optimization can
+yield arbitrarily high wins in efficiency; for example, it
+transforms `vector< vector<double> >` or `vector< hash_map<int,
+string> >` from risky liabilities into highly workable
+compositions.
+
+In order to allow fast relocation without risk, `fbvector` uses a
+trait `folly::IsRelocatable` defined in `"folly/Traits.h"`. By default,
+`folly::IsRelocatable::value` conservatively yields false. If
+you know that your type `Widget` is in fact relocatable, go right
+after `Widget`'s definition and write this:
+```cpp
+    // at global namespace level
+    namespace folly {
+      struct IsRelocatable<Widget> : boost::true_type {};
+    }
+```
+If you don't do this, `fbvector<Widget>` will fail to compile
+with a `static_assert`.
+
+### Miscellaneous
+***
+
+`fbvector` uses a careful implementation all around to make
+sure it doesn't lose efficiency through the cracks. Some future
+directions may be in improving raw memory copying (`memcpy` is
+not an intrinsic in gcc and does not work terribly well for
+large chunks) and in furthering the collaboration with
+jemalloc. Have fun!

package/external/folly/folly/docs/Format.md

@@ -0,0 +1,177 @@
+`folly/Format.h`
+----------------
+
+`folly/Format.h` provides a fast, powerful, type-safe, flexible facility
+for formatting text, using a specification language similar to Python's
+[str.format](http://docs.python.org/library/string.html#formatstrings).
+By default, it can format strings, numbers (integral and floating point),
+and dynamically-typed `folly::dynamic` objects, and can extract values from
+random-access containers and string-keyed maps.  In many cases, `format` is
+faster than `sprintf` as well as being fully type-safe.
+
+### Overview
+***
+
+Here are some code samples to get started:
+
+``` Cpp
+using folly::format;
+using folly::sformat;
+
+// Objects produced by format() can be streamed without creating
+// an intermediary string; {} yields the next argument using default
+// formatting.
+std::cout << format("The answers are {} and {}", 23, 42);
+// => "The answers are 23 and 42"
+
+// If you just want the string, though, you're covered.
+std::string result = sformat("The answers are {} and {}", 23, 42);
+// => "The answers are 23 and 42"
+
+// To insert a literal '{' or '}', just double it.
+std::cout << format("{} {{}} {{{}}}", 23, 42);
+// => "23 {} {42}"
+
+// Arguments can be referenced out of order, even multiple times
+std::cout << format("The answers are {1}, {0}, and {1} again", 23, 42);
+// => "The answers are 42, 23, and 42 again"
+
+// It's perfectly fine to not reference all arguments
+std::cout << format("The only answer is {1}", 23, 42);
+// => "The only answer is 42"
+
+// Values can be extracted from indexable containers
+// (random-access sequences and integral-keyed maps), and also from
+// string-keyed maps
+std::vector<int> v {23, 42};
+std::map<std::string, std::string> m { {"what", "answer"} };
+std::cout << format("The only {1[what]} is {0[1]}", v, m);
+// => "The only answer is 42"
+
+// format works with pairs and tuples
+std::tuple<int, std::string, int> t {42, "hello", 23};
+std::cout << format("{0} {2} {1}", t);
+// => "42 23 hello"
+
+// Format supports width, alignment, arbitrary fill, and various
+// format specifiers, with meanings similar to printf
+// "X<10": fill with 'X', left-align ('<'), width 10
+std::cout << format("{:X<10} {}", "hello", "world");
+// => "helloXXXXX world"
+
+// Field width may be a runtime value rather than part of the format string
+int x = 6;
+std::cout << format("{:-^*}", x, "hi");
+// => "--hi--"
+
+// Explicit arguments work with dynamic field width, as long as indexes are
+// given for both the value and the field width.
+std::cout << format("{2:+^*0}",
+9, "unused", 456); // => "+++456+++"
+
+// Format supports printf-style format specifiers
+std::cout << format("{0:05d} decimal = {0:04x} hex", 42);
+// => "00042 decimal = 002a hex"
+
+// Formatter objects may be written to a string using folly::to or
+// folly::toAppend (see folly/Conv.h), or by calling their appendTo(),
+// and str() methods
+std::string s = format("The only answer is {}", 42).str();
+std::cout << s;
+// => "The only answer is 42"
+
+// Decimal precision usage
+std::cout << format("Only 2 decimals is {:.2f}", 23.34134534535);
+// => "Only 2 decimals is 23.34"
+```
+
+
+### Format string syntax
+***
+
+Format string (`format`):
+`"{" [arg_index] ["[" key "]"] [":" format_spec] "}"`
+
+- `arg_index`: index of argument to format; default = next argument.  Note
+  that a format string may have either default argument indexes or
+  non-default argument indexes, but not both (to avoid confusion).
+- `key`: if the argument is a container (C-style array or pointer,
+  `std::array`, vector, deque, map), you may use this
+  to select the element to format; works with random-access sequences and
+  integer- and string-keyed maps.  Multiple level keys work as well, with
+  components separated with "."; for example, given
+  `map<string, map<string, string>> m`, `{[foo.bar]}` selects
+  `m["foo"]["bar"]`.
+- `format_spec`: format specification, see below
+
+Format specification:
+`[[fill] align] [sign] ["#"] ["0"] [width] [","] ["." precision] ["."] [type]`
+
+- `fill` (may only be specified if `align` is also specified): pad with this
+  character ('` `' (space) or '`0`' (zero) might be useful; space is default)
+- `align`: one of '`<`', '`>`', '`=`', '`^`':
+    - '`<`': left-align (default for most objects)
+    - '`>`': right-align (default for numbers)
+    - '`=`': pad after sign, but before significant digits; used to print
+            `-0000120`; only valid for numbers
+    - '`^`': center
+- `sign`: one of '`+`', '`-`', ' ' (space) (only valid for numbers)
+    - '`+`': output '`+`' if positive or zero, '`-`' if negative
+    - '`-`': output '`-`' if negative, nothing otherwise (default)
+    - '` `' (space): output '` `' (space) if positive or zero, '`-`' if negative
+- '`#`': output base prefix (`0` for octal, `0b` or `0B` for binary, `0x` or
+  `0X` for hexadecimal; only valid for integers)
+- '`0`': 0-pad after sign, same as specifying "`0=`" as the `fill` and
+  `align` parameters (only valid for numbers)
+- `width`: minimum field width. May be '`*`' to indicate that the field width
+  is given by an argument. Defaults to the next argument (preceding the value
+  to be formatted) but an explicit argument index may be given following the
+  '`*`'.
+- '`,`' (comma): output comma as thousands' separator (only valid for integers,
+  and only for decimal output)
+- `precision` (not allowed for integers):
+    - for floating point values, number of digits after decimal point ('`f`' or
+      '`F`' presentation) or number of significant digits ('`g`' or '`G`')
+    - for others, maximum field size (truncate subsequent characters)
+- '`.`' (when used after precision or in lieu of precison): Forces a trailing
+  decimal point to make it clear this is a floating point value.
+- `type`: presentation format, see below
+
+Presentation formats:
+
+- Strings (`folly::StringPiece`, `std::string`, `folly::fbstring`,
+  `const char*`):
+    - '`s`' (default)
+- Integers:
+    - '`b`': output in binary (base 2) ("`0b`" prefix if '`#`' specified)
+    - '`B`': output in binary (base 2) ("`0B`" prefix if '`#`' specified)
+    - '`c`': output as a character (cast to `char`)
+    - '`d`': output in decimal (base 10) (default)
+    - '`o`': output in octal (base 8)
+    - '`O`': output in octal (base 8) (same as '`o`')
+    - '`x`': output in hexadecimal (base 16) (lower-case digits above 9)
+    - '`X`': output in hexadecimal (base 16) (upper-case digits above 9)
+    - '`n`': locale-aware output (currently same as '`d`')
+- `bool`:
+    - default: output "`true`" or "`false`" as strings
+    - integer presentations allowed as well
+- `char`:
+    - same as other integers, but default is '`c`' instead of '`d`'
+- Floating point (`float`, `double`; `long double` is not implemented):
+    - '`e`': scientific notation using '`e`' as exponent character
+    - '`E`': scientific notation using '`E`' as exponent character
+    - '`f`': fixed point
+    - '`F`': fixed point (same as '`f`')
+    - '`g`': general; use either '`f`' or '`e`' depending on magnitude (default)
+    - '`G`': general; use either '`f`' or '`E`' depending on magnitude
+    - '`n`': locale-aware version of '`g`' (currently same as '`g`')
+    - '`%`': percentage: multiply by 100 then display as '`f`'
+
+
+### Extension
+***
+
+You can extend `format` for your own class by providing a specialization for
+`folly::FormatValue`.  See `folly/Format.h` and `folly/FormatArg.h` for
+details, and the existing specialization for `folly::dynamic` in
+`folly/dynamic-inl.h` for an implementation example.

package/external/folly/folly/docs/Function.md

@@ -0,0 +1,92 @@
+`folly/Function.h`
+------------------
+
+`folly::Function` is a polymorphic function wrapper that is not copyable and does not require the wrapped function to be copy constructible. It is similar to `std::function`, but different with respect to some interesting features.
+
+There are some limitations in `std::function` that `folly::Function` tries to avoid. `std::function` is copy-constructible and requires that the callable that it wraps is copy-constructible as well, which is a constraint that is often inconvenient. In most cases when using a `std::function` you don't make use of its copy-constructibility, so you might sometimes feel like you get back very little in return for a noticeable restriction.
+
+This restriction becomes apparent when trying to use a lambda capturing a `unique_ptr` (or any non-copyable type) as a callback for a folly::Future.
+``` Cpp
+std::unique_ptr<Foo> foo_ptr = new Foo;
+
+some_future.then(
+    [foo_ptr = std::move(foo_ptr)] mutable
+    (int x)
+    { foo_ptr->setX(x); }
+);
+```
+This piece of code did not compile before `folly::Future` started using `folly::Function` instead of `std::function` to store the callback. Because the lambda captures something non-copyable (the `unique_ptr`), it is not copyable itself. And `std::function` can only store copyable callables.
+
+The implementation of folly::Future did not make use of the copy-constructibility of `std::function` at any point. There was no benefit from the fact that the `std::function` is copy-constructible, but the fact that it can only wrap copy-constructible callables posed a restriction.
+
+A workaround was available: `folly::MoveWrapper`, which wraps an object that may be non-copyable and implements copy operations by moving the embedded object. Using a `folly::MoveWrapper`, you can capture non-copyable objects in a lambda, and the lambda itself is still copyable and may be wrapped in a `std::function`. It is a pragmatic solution for the above problem, but you have to be a little careful. The problem is that you can’t use a `MoveWrapper` anywhere where copy operations are assumed to behave like actual copy operations. Also, a `folly::MoveWrapper<std::unique_ptr<T>>` essentially behaves like `auto_ptr<T>`. Ask yourself whether you’d want to use lots of `auto_ptr`s in your codebase. And the original question still persists: we very often don’t benefit from copy-constructibility of `std::function`, so why do we have to live with this restriction? I.e. why do we have to use `MoveWrapper`?
+
+`folly::Function` is an actual solution to this problem, as it can wrap non-copyable callables, at the cost of not being copy-constructible, which more often than not is not a relevant restriction. `folly::Future` now uses `folly::Function` to store callbacks, so the good news is: the code example from the top of this note is becoming a perfectly valid way to use future callbacks. The code compiles and behaves as you would expect.
+
+Here are more details about `folly::Function`: much like `std::function`, it wraps an arbitrary object that can be invoked like a given function type. E.g. a `folly::Function<int(std::string, double)>` can wrap any callable object that returns an `int` (or something that is convertible to an `int`) when invoked with a `std::string` and a `double` argument. The function type is a template parameter of `folly::Function`, but the specific type of the callable is not.
+
+Other than copyability, there is one more significant difference between `std::function` and `folly::Function`, and it concerns const-correctness. `std::function` does not enforce const-correctness: it allows you to store mutable callables (i.e. callables that may change their inner state when executed, such as a mutable lambda) and call them in a const context (i.e. when you only have access to a const reference to the `std::function` object). For example:
+``` Cpp
+class FooBar {
+ public:
+  void call_func() const {
+    func_();
+  }
+ private:
+  std::function<void()> func_;
+};
+```
+The `call_func` member function is declared const. However, when it calls `func_()`, it may change the inner state of `func_`, and thereby the inner state of the `FooBar` object. Inside the `FooBar` class, `func_` is like a non-const method that is callable from const methods.
+
+Some people consider `std::function` in the standard broken with respect to this. (Paper N4348 explains this problem in more detail.) It also lists possible ways to fix the problem. `folly::Function`, however, goes a different way: you have to declare whether you want to store a const function, in which case you can invoke any reference (const or non-const) of the `folly::Function`, or a non-const (mutable) function, in which case you need a non-const reference to the `folly::Function` to be able to invoke it. In the above example, let’s say that `func_` stores a const function, which makes it okay that it gets invoked from `call_func` (a const method). Instead of `std::function`, you could use `folly::Function<void() const>` for the `func_` member.
+
+Const-ness is part of a function type. To illustrate:
+``` Cpp
+class Foo {
+ public:
+  int operator()() { return 1; }
+  int operator()(char const*) { return 2; }
+  int operator()(int) { return 3; }
+  int operator()(int) const { return 4; }
+  int operator()(int, int) const { return 5; }
+};
+```
+You can overload methods multiple times using different argument signatures. Const-ness is part of that signature, so even for the same set of argument types you can overload a const and a non-const version. It’s not even particularly unusual to do that. Take for instance the `begin()` method of STL container types: `begin()` returns an `iterator`, `begin() const` returns a `const_iterator`. `folly::Function` allows you to select a specific overload easily:
+``` Cpp
+folly::Function<int()> uf1 = Foo();
+// uf1() returns 1
+folly::Function<int(char const*)> uf2 = Foo();
+// uf2() returns 2
+folly::Function<int(int)> uf3 = Foo();
+// uf3() returns 3
+folly::Function<int(int) const> uf4 = Foo();
+// uf4() returns 4
+folly::Function<int(int, int) const> uf5 = Foo();
+// uf5() returns 5
+```
+If `cfoo` is a const-reference to a `Foo` object, `cfoo(int)` returns 4. If `foo` is a non-const reference to a `Foo` object, `foo(int)` returns 3. Normal const-to-non-const conversion behavior applies: if you call `foo(int, int)` it will return 5: a non-const reference will invoke the const method if no non-const method is defined. Which leads to the following behavior:
+``` Cpp
+folly::Function<int(int, int)> uf5nc = Foo();
+// uf5nc() returns 5
+```
+If you are wondering if the introduction of const function types means that you have to change lots of normal function types to const function types if you want to use `folly::Function`: not really, or at least not as much as you might think. There are only two reasons to use a `folly::Function` with a const function type:
+* a callable object defines both const and non-const `operator()` and you explicitly want to select the const one
+* you need to invoke a `folly::Function` from a const context (i.e. you only have a const reference to the `folly::Function`)
+
+In practice, you will not need the const variant very often. Adding const to a function type adds a restriction for the callable: it must not change its inner state when invoked. If you don’t care whether it does or not, don’t worry about const!
+
+A `folly::Function<R(Args...) const>` can be converted into a `folly::Function<R(Args...)>`: either way the stored callable will not change its inner state when invoked. The former type expresses and guarantees that, the latter does not. When you get rid of the const, the selected function stays the same:
+``` Cpp
+folly::Function<int(int)> uf4nc = std::move(uf4);
+// uf4nc() returns 4, not 3!
+```
+If you want to go the other way, you are talking about a (potentially dangerous) const cast: a callable that may or may not change its inner state is declared as one that guarantees not to do that. Proceed at your own risk! This conversion does not happen implicitly, though:
+``` Cpp
+folly::Function<int() const> uf1c = folly::constCastFunction(std::move(uf1));
+// uf1c() returns 1
+```
+Admittedly, seeing const function types as template parameters is unfamiliar. As far as I am aware it happens nowhere in the standard library. But it is the most consistent way to deal with the issue of const-correctness here. Const qualifiers are part of a function type, as a matter of fact. If you require a const-qualified function to be wrapped in a `folly::Function`, just declare it as that! More often than not you will find that you do not need the const qualifier. While writing the `folly::Function` implementation, a good set of unit tests had existed before the const function types got introduced. Not a single one of those unit tests had to be changed: they all compiled and passed after the introduction of const function types. Obviously new ones were added to test the const-correctness. But in your day-to-day use of `folly::Function` you won’t have to worry about const very often.
+
+Memory usage
+============
+Like most implementations of `std::function`, `folly::Function` stores small callable objects in-line and larger callable objects will be stored on the heap. `folly::Function` returns the size of the allocation it has made from its `heapAllocatedMemory()` member function; naturally it will return `0` when the callable is stored in-line.