Open rs333 opened 3 months ago
Hi, this is a good point. These two meanings of path are conflicting. I'll note that the borrow-checker-oriented meaning of "path" is based on @nikomatsakis's borrow checker formalizations. I'm going to discuss with him what he recommends for terminology here.
main
branch to see if this has already been fixed, in this file:ch04-02-references-and-borrowing.html
URL to the section(s) of the book with this problem:
ch04-02-references-and-borrowing.html
Description of the problem: The revised version of
ch04-02-references-and-borrowing.html
introduces the term Paths to meanThis seems to be a rust specific overload of the common meaning to the term path. In its present form, it can cause cognitive dissidence for the reader. (At least one and probably more :) Additionally, it appears to be technically not correct because while some paths can be put on the left hand side of an assignment, not all paths can be put on the left hand side of an assignment. E.g. I don't believe a path referring to a module item can be on the left hand side of an assignment.
Suggested fix:
A path is a sequence of one or more path segments logically separated by a namespace qualifier (::). If a path consists of only one segment, it refers to either an item or a variable in a local control scope. If a path has multiple segments, it always refers to an item.
Assignable paths
.Variables, like a. Dereferences of assignable paths, like a. Array accesses of assignable paths, like a[0]. Fields of assignable paths, like a.0 for tuples or a.field for structs (discussed next chapter). Any combination of the above, like ((*a)[0].1).