doc: fix typo and tighten wording in error sections

Changes:
- Removed superfluous "when possible"
- Fixed typo in "documentationt"
- Added missing comma
- Moved definition of error union type up to first sentence
master
Jay Weisskopf 2018-03-25 18:48:07 -04:00 committed by GitHub
parent aa2995ee39
commit 3e836f5516
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 8 deletions

View File

@ -2864,18 +2864,18 @@ const err = (error {FileNotFound}).FileNotFound;
assert to make sure the error value is in fact in the destination error set.
</p>
<p>
The global error set should generally be avoided when possible, because it prevents
the compiler from knowing what errors are possible at compile-time. Knowing
the error set at compile-time is better for generated documentationt and for
helpful error messages such as forgetting a possible error value in a {#link|switch#}.
The global error set should generally be avoided because it prevents the
compiler from knowing what errors are possible at compile-time. Knowing
the error set at compile-time is better for generated documentation and
helpful error messages, such as forgetting a possible error value in a {#link|switch#}.
</p>
{#header_close#}
{#header_close#}
{#header_open|Error Union Type#}
<p>
Most of the time you will not find yourself using an error set type. Instead,
likely you will be using the error union type. This is when you take an error set
and a normal type, and create an error union with the <code>!</code> binary operator.
An error set type and normal type can be combined with the <code>!<code>
binary operator to form an error union type. You are likely to use an
error union type more often than an error set type by itself.
</p>
<p>
Here is a function to parse a string into a 64-bit integer:
@ -6033,4 +6033,3 @@ hljs.registerLanguage("zig", function(t) {
</script>
</body>
</html>