+namespace traits_detail {
+struct InPlaceTag {};
+template <class>
+struct InPlaceTypeTag {};
+template <std::size_t>
+struct InPlaceIndexTag {};
+}
+
+/**
+ * Like std::piecewise_construct, a tag type & instance used for in-place
+ * construction of non-movable contained types, e.g. by Synchronized.
+ * Follows the naming and design of std::in_place suggested in
+ * http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0032r2.pdf
+ */
+using in_place_t = traits_detail::InPlaceTag (&)(traits_detail::InPlaceTag);
+
+template <class T>
+using in_place_type_t =
+ traits_detail::InPlaceTypeTag<T> (&)(traits_detail::InPlaceTypeTag<T>);
+
+template <std::size_t I>
+using in_place_index_t =
+ traits_detail::InPlaceIndexTag<I> (&)(traits_detail::InPlaceIndexTag<I>);
+
+inline traits_detail::InPlaceTag in_place(traits_detail::InPlaceTag = {}) {
+ return {};
+}
+
+template <class T>
+inline traits_detail::InPlaceTypeTag<T> in_place(
+ traits_detail::InPlaceTypeTag<T> = {}) {
+ return {};
+}
+
+template <std::size_t I>
+inline traits_detail::InPlaceIndexTag<I> in_place(
+ traits_detail::InPlaceIndexTag<I> = {}) {
+ return {};
+}
+
+// For backwards compatibility:
+using construct_in_place_t = in_place_t;
+
+inline traits_detail::InPlaceTag construct_in_place(
+ traits_detail::InPlaceTag = {}) {
+ return {};
+}
+
+/**
+ * Initializer lists are a powerful compile time syntax introduced in C++11
+ * but due to their often conflicting syntax they are not used by APIs for
+ * construction.
+ *
+ * Further standard conforming compilers *strongly* favor an
+ * std::initalizer_list overload for construction if one exists. The
+ * following is a simple tag used to disambiguate construction with
+ * initializer lists and regular uniform initialization.
+ *
+ * For example consider the following case
+ *
+ * class Something {
+ * public:
+ * explicit Something(int);
+ * Something(std::intiializer_list<int>);
+ *
+ * operator int();
+ * };
+ *
+ * ...
+ * Something something{1}; // SURPRISE!!
+ *
+ * The last call to instantiate the Something object will go to the
+ * initializer_list overload. Which may be surprising to users.
+ *
+ * If however this tag was used to disambiguate such construction it would be
+ * easy for users to see which construction overload their code was referring
+ * to. For example
+ *
+ * class Something {
+ * public:
+ * explicit Something(int);
+ * Something(folly::initlist_construct_t, std::initializer_list<int>);
+ *
+ * operator int();
+ * };
+ *
+ * ...
+ * Something something_one{1}; // not the initializer_list overload
+ * Something something_two{folly::initlist_construct, {1}}; // correct
+ */
+struct initlist_construct_t {};
+constexpr initlist_construct_t initlist_construct{};
+