I see. There is actually some debate about the proper behavior of `as`, but I believe the conversions that it will currently apply are:
1. Between scalar types (e.g., int to i32 and vice versa) 2. Into an object type (from @T into @Trait) 3. Borrowing (@T or ~T into &T) 4. Converting between unsafe pointer types, and I think uint to *T as well It has been proposed to limit `as` to #1 and rely instead on a combination of type ascription (`expr : T`), implicit conversions, and transmute calls for some of the others. In principle we could use library calls or traits for almost everything `as` does, except that we have been resisting the idea of compile-time evaluation of functions, meaning that we wanted to have operators for anything that would be legal as part of a constant definition. I am not sure if this principled stand is worth it, though, since `as` is a troublesome and heavily overloaded operator. Niko On Tue, Sep 10, 2013 at 10:20:02AM +1200, Nick Cameron wrote: > To clarify I meant subtyping in the sense of when are types compatible for > some kind of conversion. As opposed to subsumption or subclassing (or at > least, not limited to these cases). > > If I have |e as U| when does that succeed, and when does it fail. (Actually > from the manual it was unclear how much checking is done statically vs > dynamically, but that is kind of a tangent). Presumably the cast only > succeeds if the dynamic type of e is a subtype of U (or it can be coerced > or converted to U). An example from the manual (sect 8.1.10) shows that an > instance of an impl can be cast to the type of an implemented trait, are > there other relationships where casting is allowed? > > The manual states (sect 7.2.11.5): > > "A numeric value can be cast to any numeric type. A raw pointer value can > be cast to or from any integral type or raw pointer type. Any other cast is > unsupported and will fail to compile." > > But the last sentence is contradicted by the example in section 8.1.10 > > Separately, I remember that the various pointer types can be implicitly > converted. I couldn't find anywhere where these conversions are defined. Is > my memory bad or my search skills? > > Thanks, Nick > > > On Tue, Sep 10, 2013 at 1:34 AM, Niko Matsakis <n...@alum.mit.edu> wrote: > > > By subtyping, do you mean defining class hierarchies as in C++ or > > Java? This is currently not supported. Typically such hierarchies > > are modeled either using an `enum` (most common) or using a `trait`. > > > > Enums are perfect for cases where there is a limited set of > > possibilities. Traits are perfect for "open-ended" situations where > > you have an interface and many ways to fulfill it. The two techniques > > *can* be combined for cases that fall between the two extremes. > > > > We have considered adding a limited form of struct inheritance (so > > that one struct can build on another) but afaik this feature is not > > planned in the short term. > > > > > > Niko > > > > On Mon, Sep 09, 2013 at 07:04:07PM +1200, Nick Cameron wrote: > > > Is there somewhere I can look for a description of subtyping in Rust? I > > > don't see any mention of it in the manual or tutorial. > > > > > > Thanks, Nick > > > > > _______________________________________________ > > > Rust-dev mailing list > > > Rust-dev@mozilla.org > > > https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
