Fix typos and make somethings clearer

doc/src/example_overloading.md

@@ -12,17 +12,38 @@ stackoverflow [here](http://stackoverflow.com/questions/30189926/metaprograming-
 The user would like to write `stringify` to call `to_string` where applicable
 and fallback on using `sstream` to convert to a string. Most of the top
 answers usually involve some amount of metaprogramming using either `void_t`
-or `is_detected`(see [n4502](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4502.pdf)). However, with the Fit library it can simply be written like
+or `is_detected`(see [n4502](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4502.pdf)): 
+
+    template<class T>
+    using to_string_t = decltype(std::to_string(std::declval<T>()));
+
+    template<class T>
+    using has_to_string = std::experimental::is_detected<to_string_t, T>;
+
+    template<typename T> 
+    typename std::enable_if<has_to_string<T>{}, std::string>::type 
+    stringify(T t)
+    {
+        return std::to_string(t);
+    }
+    template<typename T> 
+    typename std::enable_if<!has_to_string<T>{}, std::string>::type 
+    stringify(T t)
+    {
+        return static_cast<std::ostringstream&>(std::ostringstream() << t).str();
+    }
+
+However, with the Fit library it can simply be written like
 this:
 
     FIT_STATIC_LAMBDA_FUNCTION(stringify) = conditional(
-        [](auto x) FIT_RETURNS(to_string(x)),
-        [](auto x) FIT_RETURNS(static_cast<ostringstream&>(ostringstream() << x).str())
+        [](auto x) FIT_RETURNS(std::to_string(x)),
+        [](auto x) FIT_RETURNS(static_cast<std::ostringstream&>(std::ostringstream() << x).str())
     );
 
-So, using [`FIT_RETURNS`](/include/fit/returns) no only deduces the return type for the function, but it also constrains the function on whether the expression is valid or not either. So by writing `FIT_RETURNS(to_string(x))` then the first function will try to call `to_string` function if possible. If not, then the second function will be called. 
+So, using [`FIT_RETURNS`](/include/fit/returns) not only deduces the return type for the function, but it also constrains the function on whether the expression is valid or not either. So by writing `FIT_RETURNS(std::to_string(x))` then the first function will try to call `std::to_string` function if possible. If not, then the second function will be called. 
 
-The second function still uses [`FIT_RETURNS`](/include/fit/returns), so the function will still be constrained by whether the `<<` stream operator can be used. Although it may seem unnecsarry because there is not another function, however, this makes the function composable. So we could use this to define a `serialize` function that tries to call stringify first, otherwise it looks for the member `.serialize()`:
+The second function still uses [`FIT_RETURNS`](/include/fit/returns), so the function will still be constrained by whether the `<<` stream operator can be used. Although it may seem unnecessary because there is not another function, however, this makes the function composable. So we could use this to define a `serialize` function that tries to call `stringify` first, otherwise it looks for the member `.serialize()`:
 
     FIT_STATIC_LAMBDA_FUNCTION(serialize) = conditional(
         [](auto x) FIT_RETURNS(stringify(x)),

doc/src/example_polymorphic_constructors.md

@@ -29,4 +29,4 @@ has to be written over and over again for template classes:
 
 The [`construct`](include/fit/construct) function takes care of all this boilerplate, and the above can be simply written like this:
 
-    FIT_STATIC_FUNCTION(make_tuple) = construct<std::tuple>().by(decay());
+    FIT_STATIC_FUNCTION(make_tuple) = construct<std::tuple>();

doc/src/example_print.md

@@ -27,7 +27,7 @@ The Fit library provides several ways to do overloading. One of the ways is with
         }
     );
 
-The `-> decltype(std::cout << x, void())` is added to the function to constrain it on whether `std::cout << x` is a valid expression. Then the `void()` is used to return `void` from the function. So, now the function can called with a vector:
+The `-> decltype(std::cout << x, void())` is added to the function to constrain it on whether `std::cout << x` is a valid expression. Then the `void()` is used to return `void` from the function. So, now the function can be called with a vector:
 
     std::vector<int> v = { 1, 2, 3, 4 };
     print(v);

doc/src/faq.md

@@ -4,7 +4,7 @@ FAQ
 #### Q: Why is `const` required for the call operator on function objects?
 
 Mutable function objects are not prohibited, they just need to be explicit by
-using the [`mutable_adaptor`](/include/fit/mutable). The main reason for this, is that it can lead to
+using the adaptor [`mutable_`](/include/fit/mutable). The main reason for this, is that it can lead to
 many suprising behaviours. Many times function objects are copied by value
 everywhere. For example,
 
@@ -60,7 +60,7 @@ unlikely considering that C++ will probably get constexpr lambdas and inline
 variables in the future.
 
 Alternatively, the factory pattern can be used instead of
-`FIT_STATIC_LAMBDA_FUNCTION`, which doesn't require an reinterpret cast:
+[`FIT_STATIC_LAMBDA_FUNCTION`](FIT_STATIC_LAMBDA_FUNCTION), which doesn't require an reinterpret cast:
 
 ```cpp
 struct sum_factory

doc/src/index.md

@@ -36,5 +36,5 @@ This requires a C++11 compiler. There are no third-party dependencies. This has
 Contexpr support
 ----------------
 
-Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the `FIT_STATIC_FUNCTION` and `FIT_STATIC_LAMBDA_FUNCTION` constructs.
+Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the [`FIT_STATIC_FUNCTION`](FIT_STATIC_FUNCTION) and [`FIT_STATIC_LAMBDA_FUNCTION`](FIT_STATIC_LAMBDA_FUNCTION) constructs.
 

include/fit/unpack_sequence.hpp

@@ -12,7 +12,7 @@
 /// ===============
 /// 
 /// How to unpack a sequence can be defined by specializing `unpack_sequence`.
-/// By default, `std::tuple` can be used with unpack.
+/// By default, `std::tuple` is already specialized.
 /// 
 /// Synopsis
 /// --------