[rust-dev] mode removal

Niko Matsakis niko at alum.mit.edu
Wed Aug 8 15:14:43 PDT 2012


I am working now on removing modes from isolated modules in rustc. The 
basic idea is to employ these two lint modes:

#[warn(deprecated_mode)];
#[warn(deprecated_pattern)];

They both give warnings when you are relying on defaults that will 
change, possibly for the worse.  Both of them have an idea of a type 
that is "expensive or inadvisable to copy".  This consists of all types 
that are not implicitly copyable (that is, unique ptrs or types with 
mutable contents) but also values which are large (more than 4 fields, I 
think?), type parameters, and some other categories I don't recall.  It 
also always warns about ~str or ~[], even though by default those are 
considered implicitly copyable.

In the case of function parameters, if you get a warning, you have two 
choices.  (1) Convert the type to something implicitly copyable, usually 
by changing the type T to a region pointer &T. (2) If you did want a 
copy, then use by-copy mode (+).  If you use any other mode besides the 
default or +, you will get a warning.

In the case of patterns, you can choose either the copy or the ref 
keyword.  So you can write:

     match foo {
         bar(ref x) => {...}
     }

Note that `ref x` will mean that `x` has a region type `&T`.  If you 
wanted to copy the value out, you could do:

     match foo {
         bar(copy x) => {...}
     }

in which case `x` will have the type `T`.

When converting, you will often hit borders between code that is region 
converted and code that is not.  Here you may need to add dummy `*` or 
`&` to make the type work out.  For example, if you call a function with 
a parameter that uses `&&` mode but you have a value of type `&T`, you 
have to write `foo(*bar)`, even though no pointer deref actually 
occurs.  This is similar to C++ and the mismatch betweeen `T&` and `T*`.

I am currently working on converting the `infer.rs` module and some of 
the type checker.  It's somewhat tedious work.  It may be worth waiting 
until I'm done because I encounter small bugs from time to time that 
require snapshots.


Niko


More information about the Rust-dev mailing list