diff --git a/docs/source/api/usertype.rst b/docs/source/api/usertype.rst
index eb076981..4d24b472 100644
--- a/docs/source/api/usertype.rst
+++ b/docs/source/api/usertype.rst
@@ -196,7 +196,7 @@ Sol can adjust pointers from derived classes to base classes at runtime, but it
 
 If your class has no complicated™ virtual inheritance or multiple inheritance, than you can try to sneak away with a performance boost from not specifying any base classes and doing any casting checks. (What does "complicated™" mean? Ask your compiler's documentation, if you're in that deep.)
 
-For the rest of us safe individuals out there: You must specify the ``sol::base_classes`` tag with the ``sol::bases<Types...>()`` argument, where ``Types...`` are all the base classes of the single type ``T`` that you are making a usertype out of. If you turn exceptions off and are also completely mad and turn off :doc:`run-time type information<../rtti>` as well, we fallback to a id-based  system that still requires you to specifically list the base classes as well. For example:
+For the rest of us safe individuals out there: You must specify the ``sol::base_classes`` tag with the ``sol::bases<Types...>()`` argument, where ``Types...`` are all the base classes of the single type ``T`` that you are making a usertype out of.
 
 .. note::
 
@@ -214,6 +214,10 @@ For the rest of us safe individuals out there: You must specify the ``sol::base_
 		virtual int call() override { return 20; } 
 	};
 
+.. warning::
+
+	Sol currently attempts to link base class methods and variables with their derived classes with an undocumented, unsupported feature, provided you specify ``sol::base_classes<...>``. Unfortunately, this can come at the cost of prformance, depending on how "far" the base is from the derived class in the bases lookup list. If you do not want to suffer the performance degradation while we iron out the kinks in the implementation (and want it to stay performant forever), please specify all the base methods on the derived class in the method listing you write. In the future, we hope that with reflection we will not have to worry about this.
+
 Then, to register the base classes explicitly:
 
 .. code-block:: cpp
diff --git a/docs/source/codecvt.rst b/docs/source/codecvt.rst
index 38b57245..ff901ede 100644
--- a/docs/source/codecvt.rst
+++ b/docs/source/codecvt.rst
@@ -5,4 +5,4 @@ because this is surprisingly hard using standard C++
 
 Individuals using Visual Studio 2015, or on Windows with the VC++ and MinGW compilers (possibly Clang++ on Windows as well) have ``<codecvt>`` headers, and thusly Sol will attempt to include it. Individuals on GC 4.9.x, Clang 3.5.x, Clang 3.6.x do not seem to have ``<codecvt>`` shipped with the standard library that comes with installation of these compilers. If you want ``std::wstring``, ``std::u16string``, ``std::u32string`` automatic handling then you need to make sure you have those headers and then define ``SOL_CODECVT_SUPPORT``.
 
-ThePhD did not want this to have to be a thing, but slow implementations and such force my hand. When GCC 7.x comes out, ThePhD will consider removing the effect of defining this macro and leaving <codecvt> support in at all times.
+ThePhD did not want this to have to be a thing, but slow implementations and such force their hand. When GCC 7.x comes out, ThePhD will consider removing the effect of defining this macro and leaving <codecvt> support in at all times.