Skip to content

Types chapter cleanup and new sections #101

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.

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 2 commits into from
Sep 22, 2017

Conversation

matthewjasper
Copy link
Contributor

@matthewjasper matthewjasper commented Aug 26, 2017

Changes to existing sections (first commit):

  • Avoid using 'type constructor'
  • Give a definition and more complete list of primitive types
  • Use 'slice' for the unsized type [T]
  • Don't use Vec<T> in the slice example
  • Use the term 'variant', instead of 'variant constructor'
  • Remove description of error E0073 (now removed) when describing rules for recursive types.
  • Say some more about references and pointers (including RFC 1135)
  • Use compile_fail for examples that show compiler errors
  • Mention that structs and variants also create function item types
  • Try to make it clearer that/why Fn can be implemented by move closures
  • List object safety rules (RFC 255)
  • Remove an incorrect statement about which type is the receiver.

Additional sections (second commit):

  • Mutable references
  • DSTs (includes documenting RFC 490, RFC 546)
  • Interior mutability
  • Unions

@matthewjasper
Copy link
Contributor Author

Also, since one of the rules listed for recursive types was out of date, does anyone know what "Recursive type definitions can cross module boundaries, but not module visibility boundaries, or crate boundaries (in order to simplify the module system and type checker)." is/was supposed to mean?

Copy link
Contributor

@Havvy Havvy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall. Some grammar fixes and rewording suggested.

src/types.md Outdated
Most types have a fixed size that is known at compile time and implement the
trait [`Sized`]. A type with a size that is known only at run-time is called a
_dynamically sized type_ (_DST_) or unsized type. [Slices] and [trait objects]
are two of the most DSTs. Such types can only be used in certain cases:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/of the most/examples of/

If you want to say "of the most common", I'd personally suggest against that as it's an empirical fact.

src/types.md Outdated
sized types
* Pointers to slices also store the number of elements of the slice.
* Pointers to trait objects also store a pointer to a vtable.
* Traits may be implemented for DSTs, this means that `Self` is not assumed to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should definitely be a period instead of a comma after DSTs. I think this can be shortened considerably. Consider the following, where elsewhere is a link to wherever talks about the Sized trait and where it is automatically inferred.

"Traits can be implemented for DSTs. Unlike elsewhere Self: ?Sized by default in trait definitions."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about https://doc.rust-lang.org/nightly/reference/the-sized-trait.html and a later PR, we can fill in that section?

src/types.md Outdated
* Pointers to trait objects also store a pointer to a vtable.
* Traits may be implemented for DSTs, this means that `Self` is not assumed to
implement `Sized` in trait definitions by default.
* DSTs can be used as type parameters with a bound of `?Sized`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does markdown support <abbr>? If so, we should use it everywhere DST is used. I think?

src/types.md Outdated
References prevent a value being both aliased and mutated: mutable references
don't allow a value to be aliased and shared references prevent a value from
being mutated. Sometimes this is too restrictive. The type
[`std::cell::UnsafeCell<T>`](../std/cell/struct.UnsafeCell.html) provides an
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The type should be core::cell::UnsafeCell linking to https://doc.rust-lang.org/nightly/core/cell/struct.UnsafeCell.html

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reference usually links to the re-export in std (maybe this should change).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally speaking, we link to std and not core.

(maybe this should change)

Yeah possibly, it's a tough problem.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm the odd one out on this one. Everybody else thinks it is better to link to std, not core.

src/types.md Outdated
being mutated. Sometimes this is too restrictive. The type
[`std::cell::UnsafeCell<T>`](../std/cell/struct.UnsafeCell.html) provides an
unsafe API that allows a type to own a `T` that can be mutated through a shared
reference to the `UnsafeCell` (there is no change to mutable references).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parenthetical should be its own sentence and copy verbiage from the UnsafeCell docs themselves.

"It is undefined behavior to have multiple &mut UnsafeCell<T> aliases."

src/types.md Outdated
reference to the `UnsafeCell` (there is no change to mutable references).

The standard library provides a variety of different types that safely wrap
this functionality. For example `std::cell::RefCell<T>` uses run-time borrow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Link?

src/types.md Outdated
The standard library provides a variety of different types that safely wrap
this functionality. For example `std::cell::RefCell<T>` uses run-time borrow
checks to ensure the usual rules around multiple references. The
`std::sync::atomic` module contains types that wrap a value that is only
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Link?

src/types.md Outdated
example in `std::rc::Rc<T>`.


## Dynamically sized types
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The more I look at this section, the more I wonder if this section should be on the Sized trait itself. The other types in this chapter (except Self...) are non-overlapping, whereas DSTs are a facet of a type.

@matthewjasper
Copy link
Contributor Author

I've moved the interior mutability and DST sections to their own pages following @Havvy's comment above.
Also the trait object section now has more examples about default lifetimes and I've tried to make the interior mutability section clearer.

@Havvy Havvy merged commit ef15971 into rust-lang:master Sep 22, 2017
@Havvy
Copy link
Contributor

Havvy commented Sep 22, 2017

Thanks ❤️

@matthewjasper matthewjasper deleted the type-cleanup branch October 18, 2018 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants