Introduce syntax like:
iface animal { ... }
class cat implements animal { ... }
to allow classes to implement ifaces. Casting classes to ifaces
is *not* yet supported. ifaces that a class implements are not
yet included in metadata.
The syntax is subject to change, and may go away completely if we
decide to use duck typing to relate classes with ifaces (see
http://smallcultfollowing.com/babysteps/blog/2012/04/10/declared-vs-duckish-typing/ )
Classes can have ty params now. So can methods inside classes.
That was probably true before, but now it should still work if you
call methods in a class that's defined in a different crate. Yay!
`use` statement may introduce an crate name alias. This patch always
uses the link attrbute "name" as the crate's name when building the
crate map.
Closes#1706
get_with_default (nee from_maybe) => get_default
with_option (nee maybe) => map_default
with_option_do (nee may) => iter
As per discussion of 21be1379d5
Most could use the each method, but because of the hack used to
disambiguate old- and new-style loops, some had to use vec::each.
(This hack will go away soon.)
Issue #1619
- we now distinguish bound/free parameters (see region-param
test case for why this is necessary)
- we also track bounds on region variables
- also, restructure fold_ty() to have multiple variants without
duplication instead of one overloaded folder. This also allows
for using block functions.
from_maybe => get_with_default
maybe => with_option
may => with_option_do
I know these names are kind of ridiculous, but it's the best I could think of.
Feel free to bikeshed. Closes#2081
All field or method references within a class must begin with "self." now.
A bare reference to a field or method in the same class will no longer
typecheck.
Allow writing self.f() within a class that has a method f. In a future
commit, this syntax will be required. For now, you can write either
self.f() or f().
I added a "privacy" field to all methods (whether class methods or not),
which allowed me to refactor the AST somewhat (getting rid of the
class_item type; now there's just class_member).
1. Enforce mutability declarations on class fields. Don't allow any
mutation of class fields not declared as mutable (except inside the
constructor).
2. Handle classes correctly in shape (treat classes like records).
This change uses the same code for handling the "self" reference for
classes as is already used for impls/ifaces. This allows removing the
extra maybe_self_id argument (which was just for classes) to trans_closure
that I added before. I also rewrote the translation for class ctors so
that it doesn't generate new AST nodes (instead translating directly).
Also changed visit so that it visits class ctors correctly with visit_fn,
and changed typestate to not do return-checking when visiting a class ctor.
Cross-crate method calls don't work yet. Added
run-pass/class-method-cross-crate to test that, but it's xfailed
References to fields within methods don't work yet. Added
run-pass/class-methods to test that, but it's also xfailed
In particular, use the ast::method type to represent a class method,
and try to reuse as much iface code as possible. (This makes sense now
since I'll be allowing polymorphic class methods.)
Cross-crate metadata for classes works well enough that programs with
classes in other crates compile successfully, but output wrong results.
Checking in work so far to avoid merge hassles. (Tests are xfailed.)
This will make it easier to convert crate_ctxt into a region pointer, since
there are functions that return crate contexts. There would be no way to type
these functions if crate_ctxt had to be an inferred region pointer.
We used to generate a module T with a serialize() and deserialize() fn,
but this was suboptimal for a number of reasons:
- it required moving serialization into core so that uint etc worked
- it was harder to override the serialization behavior locally
(this is now trivial)
- Move io, run and rand to core.
- Remove incorrect ctypes module (use libc).
- Remove os-specific modules for os and fs.
- Split fs between core::path and core::os.
As per discussion on IRC. I am about to file an RFC for further
discussion about the more general issue of whether to enforce
invariants through types, typestate, or dynamic checks, but for now,
removing the misleading name "last_unsafe".
