Move FAQ point string and byte type details

Chris Ward · Chris Ward · commit 38dcf6fb847a · 2018-07-10T13:44:36.000+02:00
diff --git a/docs/frequently-asked-questions.rst b/docs/frequently-asked-questions.rst
@@ -199,29 +199,6 @@ See `ping.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/cont
 and `pong.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/45_pong.sol>`_.
 
 
-
-What is the relationship between ``bytes32`` and ``string``? Why is it that ``bytes32 somevar = "stringliteral";`` works and what does the saved 32-byte hex value mean?
-========================================================================================================================================================================
-
-The type ``bytes32`` can hold 32 (raw) bytes. In the assignment ``bytes32 samevar = "stringliteral";``,
-the string literal is interpreted in its raw byte form and if you inspect ``somevar`` and
-see a 32-byte hex value, this is just ``"stringliteral"`` in hex.
-
-The type ``bytes`` is similar, only that it can change its length.
-
-Finally, ``string`` is basically identical to ``bytes`` only that it is assumed
-to hold the UTF-8 encoding of a real string. Since ``string`` stores the
-data in UTF-8 encoding it is quite expensive to compute the number of
-characters in the string (the encoding of some characters takes more
-than a single byte). Because of that, ``string s; s.length`` is not yet
-supported and not even index access ``s[2]``. But if you want to access
-the low-level byte encoding of the string, you can use
-``bytes(s).length`` and ``bytes(s)[2]`` which will result in the number
-of bytes in the UTF-8 encoding of the string (not the number of
-characters) and the second byte (not character) of the UTF-8 encoded
-string, respectively.
-
-
 Can a contract pass an array (static size) or string or ``bytes`` (dynamic size) to another contract?
 =====================================================================================================
 
diff --git a/docs/types.rst b/docs/types.rst
@@ -302,12 +302,18 @@ a non-rational number).
     uint128 a = 1;
     uint128 b = 2.5 + a + 0.5;
 
-.. index:: literal, literal;string, string
+.. index:: literal, literal;string, string, string length, string size
 
 String Literals
 ---------------
 
-String literals are written with either double or single-quotes (``"foo"`` or ``'bar'``).  They do not imply trailing zeroes as in C; ``"foo"`` represents three bytes not four.  As with integer literals, their type can vary, but they are implicitly convertible to ``bytes1``, ..., ``bytes32``, if they fit, to ``bytes`` and to ``string``.
+String literals are written with either double or single-quotes (``"foo"`` or ``'bar'``).  They do not imply trailing zeroes as in C; ``"foo"`` represents three bytes not four.  As with integer literals, their type can vary, but they are implicitly convertible to ``bytes1``, ..., ``bytes32``, if they fit, to ``bytes`` and to ``string``. For example, with ::
+
+  bytes32 samevar = "stringliteral";
+
+The string literal is interpreted in its raw byte form and if you inspect ``somevar``, you see a 32-byte hex value, which is the ``"stringliteral"`` in hex.
+
+Using a ``string`` type is basically identical to ``bytes``, but it is assumed to hold the UTF-8 encoding of a real string. Since ``string`` UTF-8 encoding of some characters takes more than a single byte, it is quite expensive to compute the number of characters in the string. Because of this, solidity does not support length methods ``string s; s.length``, or index access ``s[2]``. If you want to access the low-level byte encoding of the string, you can use ``bytes(s).length`` and ``bytes(s)[2]`` which returns the number of bytes in the UTF-8 encoding of the string (not the number of characters) and the second byte (not character) of the UTF-8 encoded string, respectively.
 
 String literals support escape characters, such as ``\n``, ``\xNN`` and ``\uNNNN``. ``\xNN`` takes a hex value and inserts the appropriate byte, while ``\uNNNN`` takes a Unicode codepoint and inserts an UTF-8 sequence.
 
@@ -989,4 +995,3 @@ converted to a matching size. This makes alignment and padding explicit::
     uint16 x = 0xffff;
     bytes32(uint256(x)); // pad on the left
     bytes32(bytes2(x)); // pad on the right
-
