commit c0a69a50755b4364e18726b06cbc193d208b131d (tree)
parent aa2995ee395b2c1329a61513debcac6225fcb8a8
Author: Andrew Kelley <superjoe30@gmail.com>
Date: Sun, 25 Mar 2018 23:31:12 -0400
Merge pull request #860 from jayschwa/patch-1
doc: fix typo and tighten wording in error sections
Diffstat:
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/doc/langref.html.in b/doc/langref.html.in
@@ -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>
-