Move type related FAQ points #4499

ChrisChinchilla · 2018-07-12T12:58:24Z

Partially closes #1219 including some formatting and language fixes in related points, additional questions below.

Also closes #2178.

ChrisChinchilla · 2018-07-12T12:59:14Z

docs/types.rst

@@ -609,6 +646,21 @@ number of bytes, always use one of ``bytes1`` to ``bytes32`` because they are mu
    that you are accessing the low-level bytes of the UTF-8 representation,
    and not the individual characters!

+You can initialise a statically sized memory array inline using syntax such as ``string[] memory myarray = new string[](4);``. For example.


This isn't quite complete, I'd like to match the text and the example.

Perhaps better to move this into "Array literals / inline arrays"

ChrisChinchilla · 2018-07-12T12:59:39Z

docs/types.rst

+
+.. _type-deduction:
+
+Type Deduction


Not sure where this came from as I didn't add it, possibly from develop branch.

chriseth · 2018-07-12T15:08:38Z

docs/types.rst

-operators. For a quick reference of the various operators, see :ref:`order`.
+Types can interact in expressions containing operators. For a quick reference of the various operators, see :ref:`order`.
+
+Types can not return an ``undefined`` or "null" value. To handle any unexpected values you can 'throw' on error, which also reverts the whole transaction.


Better: The concept of "undefined" or "null" does not exist in Solidity.

Also: Don't mention throw, rather use revert("Error message").

chriseth · 2018-07-12T15:09:28Z

docs/types.rst

@@ -52,6 +51,12 @@ Operators:
 * Bit operators: ``&``, ``|``, ``^`` (bitwise exclusive or), ``~`` (bitwise negation)
 * Arithmetic operators: ``+``, ``-``, unary ``-``, unary ``+``, ``*``, ``/``, ``%`` (remainder), ``**`` (exponentiation), ``<<`` (left shift), ``>>`` (right shift)

+The bit size of an integer determines its range, for example, for ``uint256``, this is 0 up to 2 :sup:`256` -1. If the result of an operation doesn't fit inside this range, it is truncated. These truncations can have `serious consequences <https://en.bitcoin.it/wiki/Value_overflow_incident>`_, so use code like the below to avoid certain attacks and check a value is what you expect it to be.


The truncations themselves do not have serious consequences, rather not taking them into account might.

chriseth · 2018-07-12T15:09:56Z

docs/types.rst

+
+::
+
+    require((balanceOf[_to] + _value) >= balanceOf[_to]);


This only works for checking overflow for unsigned types, so we should make that clear.

chriseth · 2018-07-12T15:11:14Z

docs/types.rst


-.. index:: literal, bytes
+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.


Whether or not it is hex depends on the tool you use.

Clarified, might be nice to add a list at some point, will save that for a separate issue.

chriseth · 2018-07-12T15:12:08Z

docs/types.rst

-.. index:: literal, bytes
+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 accessing an item at an array index ``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.


Not only "using" but also the type itself is basically identical to bytes.

Note that strings is not a string literal, it is a string type, so we should probably move this somewhere else.

Attempted to split and consolidate, more changes might be required, again, probably in a new PR.

chriseth · 2018-07-12T15:13:38Z

docs/types.rst

+
+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 accessing an item at an array index ``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.


Pleas clarify whether \u takes hex or decimal.

I think done. I couldn't find any definitive Solidity doc mentioning it, so extrapolated from C and JavaScript docs.

chriseth · 2018-07-12T15:14:37Z

docs/types.rst

+
+.. index:: copy an array, copy a struct
+
+Copying Reference Types


I think this should also go into the newly created "copying, references, function calls, whatever" section with a link from here.

@chriseth I think we should make this a new PR, so I'll revert this addition, keep the removal from the FAQ document and I'll stash this text for a forthcoming new PR.

axic · 2018-09-26T21:37:33Z

docs/types.rst

+
+::
+
+    require((balanceOf[_to] + _value) >= balanceOf[_to]);


I think this is a bad idea without explanation.

@axic I thought the text above and the example were enough, but added a little more, hopefully I got it right.

Move type related FAQ points

c8ed532

ChrisChinchilla commented Jul 12, 2018

View reviewed changes

chriseth reviewed Jul 12, 2018

View reviewed changes

Chris Ward added 2 commits July 16, 2018 12:17

Changes from review except copying section

001eae6

Revert copying refernce types for now

40d5ef4

ChrisChinchilla self-assigned this Jul 16, 2018

ChrisChinchilla added documentation 📖 in progress labels Jul 16, 2018

axic removed the in progress label Aug 2, 2018

ChrisChinchilla mentioned this pull request Aug 22, 2018

doc: explain that state variables can be initialized inline #2178

Closed

axic reviewed Sep 26, 2018

View reviewed changes

Clarify code example

ed7a631

chriseth closed this Nov 12, 2018

ChrisChinchilla deleted the faq-reorg-types branch November 14, 2018 16:21

ChrisChinchilla mentioned this pull request Nov 15, 2018

DOCS: Remove length related FAQ item #5439

Merged

6 tasks


		.. index:: literal, bytes
		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 accessing an item at an array index ``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.


		.. index:: copy an array, copy a struct

		Copying Reference Types

Move type related FAQ points #4499

Move type related FAQ points #4499

Uh oh!

Conversation

ChrisChinchilla commented Jul 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

axic Sep 26, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ChrisChinchilla commented Jul 12, 2018 •

edited

Loading

axic Sep 26, 2018 •

edited

Loading