Skip to content

Fix some typos and grammar in the docs. #978

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 26, 2011
Merged

Fix some typos and grammar in the docs. #978

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions doc/rust.texi
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -185,7 +185,7 @@ features of Rust, relative to other languages.
The initialization state of every slot is statically computed as part of the
typestate system (see below), and requires that all slots are initialized
before use. There is no @code{null} value; uninitialized slots are
uninitialized, and can only be written to, not read.
uninitialized and can only be written to, not read.

The common use for @code{null} in other languages -- as a sentinel value -- is
subsumed into the more general facility of disjoint union types. A program
Expand All @@ -197,10 +197,10 @@ must explicitly model its use of such types.
Like many @emph{actor} languages, Rust provides an isolation (and concurrency)
model based on lightweight tasks scheduled by the language runtime. These
tasks are very inexpensive and statically unable to manipulate one another's
local memory. Breaking the rule of task isolation is only possible by calling
local memory. Breaking the rule of task isolation is possible only by calling
external (C/C++) code.

Inter-task communication is typed, asynchronous and simplex, based on passing
Inter-task communication is typed, asynchronous, and simplex, based on passing
messages over channels to ports.

@sp 1
Expand Down Expand Up @@ -1136,7 +1136,7 @@ module bar @{
@end example

In future versions of Rust, user-provided extensions to the compiler will be able
to use interpret attributes. When this facility is provided, a distinction will be
to interpret attributes. When this facility is provided, a distinction will be
made between language-reserved and user-available attributes.

At present, only the Rust compiler interprets attributes, so all attribute
Expand Down Expand Up @@ -1328,13 +1328,13 @@ Local slots are always implicitly mutable.
Local slots are not initialized when allocated; the entire frame worth of
local slots are allocated at once, on frame-entry, in an uninitialized
state. Subsequent statements within a function may or may not initialize the
local slots. Local slots can only be used after they have been initialized;
local slots. Local slots can be used only after they have been initialized;
this condition is guaranteed by the typestate system.

References are created for function arguments. If the compiler can not prove
that the referred-to value will outlive the reference, it will try to set
aside a copy of that value to refer to. If this is not sematically safe (for
example, if the referred-to value contains mutable fields), it reject the
example, if the referred-to value contains mutable fields), it will reject the
program. If the compiler deems copying the value expensive, it will warn.

A function can be declared to take an argument by mutable reference. This
Expand Down Expand Up @@ -1996,7 +1996,7 @@ The output type of an iterator is the type of value that the function will
@code{put}, before it eventually evaluates a @code{ret} or @code{be} expression
of type @code{()} and completes its execution.

An iterator can only be called in the loop header of a matching @code{for
An iterator can be called only in the loop header of a matching @code{for
each} loop or as the argument in a @code{put each} expression.
@xref{Ref.Expr.Foreach}.

Expand Down Expand Up @@ -2108,10 +2108,10 @@ The constructors of a @code{tag} type may be recursive: that is, each constructo
may take an argument that refers, directly or indirectly, to the tag type the constructor
is a member of. Such recursion has restrictions:
@itemize
@item Recursive types can only be introduced through @code{tag} constructors.
@item Recursive types can be introduced only through @code{tag} constructors.
@item A recursive @code{tag} item must have at least one non-recursive
constructor (in order to give the recursion a basis case).
@item The recursively argument of recursive tag constructors must be @emph{box}
@item The recursive argument of recursive tag constructors must be @emph{box}
values (in order to bound the in-memory size of the constructor).
@item Recursive type definitions can cross module boundaries, but not module
@emph{visibility} boundaries, nor crate boundaries (in order to simplify the
Expand Down Expand Up @@ -2360,7 +2360,7 @@ values similar to the record type-constructor. The differences are as follows:

@itemize
@item tuple elements cannot be mutable, unlike record fields
@item tuple elements are not named, and can only be accessed by pattern-matching
@item tuple elements are not named and can be accessed only by pattern-matching
@end itemize

Tuple types and values are denoted by listing the types or values of
Expand Down