Skip to content

Commit

Permalink
Revision: change iter_move to into_iter
Browse files Browse the repository at this point in the history
  • Loading branch information
aturon committed Sep 12, 2014
1 parent e0acdf4 commit bfd18a8
Showing 1 changed file with 4 additions and 14 deletions.
18 changes: 4 additions & 14 deletions active/0052-ownership-variants.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,8 +45,10 @@ If `foo` uses/produces an immutable borrow by default, use:
* The `_mut` suffix (e.g. `foo_mut`) for the mutably borrowed variant.
* The `_move` suffix (e.g. `foo_move`) for the owned variant.

A consequence is that the iterator methods become: `iter`, `iter_mut`,
and `iter_move`.
However, in the case of iterators, the moving variant can also be
understood as an `into` conversion, `into_iter`, and `for x in v.into_iter()`
reads arguably better than `for x in v.iter_move()`, so the convention is
`into_iter`.

**NOTE**: This convention covers only the *method* names for
iterators, not the names of the iterator types. That will be the
Expand Down Expand Up @@ -142,15 +144,3 @@ Another option would be `val` or `value` instead of `owned`. This
suggestion plays into the "by reference" and "by value" distinction,
and so is even more congruent with `ref` than `move` is. On the other
hand, it's less clear/evocative than either `move` or `owned`.

## `into_iter`

For the case of iteration, at least, it would make some sense to
signal ownership transfer by treating the owned version as a
conversion, `into_iter`. The main downside is that it would go against
the general convention for ownership variants (and cannot be used as
the general convention, because not all cases can be seen as
conversions).

Moreover, it's strange to see just the owning variant as a conversion
-- why not `as_iter`, `as_iter_mut`, and `into_iter`?

0 comments on commit bfd18a8

Please sign in to comment.