Proposal: Change terminology from "trait object" to "dynamic trait"

[Centril]

What we wish to Communicate

Consider the following program fragment:

let x: Box<dyn Trait>;

What can we say about x, and what should we say about x? I’ll try to jot down answers to the first part here.

1. Existentially quantified

To form a Box<dyn Trait> you must have some object y where typeof(y): Trait which you can then Box::new(y) on.

If we want to be a bit more clear about what is happening with Box<dyn Trait>, we could use this pseudo-Rust:

// "There exists some `T: Trait`"
let x: Box<for<T: Trait> T>;

or in actual Haskell (a larger example):

{-# LANGUAGE ExistentialQuantification, KindSignatures, ConstraintKinds #-}

import Data.Kind
import Control.Monad

-- This is morally equivalent to `dyn`.
data Dyn (c :: * -> Constraint) = forall (t :: *). (c t :: Constraint) => D t

-- Or unannotated:
-- data Dyn c = forall t. c t => D t

-- Morally equivalent to `Vec<Box<dyn Debug>>`.
heteroList :: [Dyn Show]
heteroList = [D (), D 5, D True]

-- A program that prints out each element of the list above
-- to the terminal on a separate line.
main :: IO ()
main = forM_ heteroList $ \(D x) -> print x

Another way to think about existential quantification is that the type variable t is erased here, and hence type erasure.

2. Supports the operations of Trait

We could say:

let x: Box<for<T> T>;

which might be well-formed in our pseudo-Rust, but it would also be useless (we can’t do anything useful with x).

Instead x: Box<dyn Trait> supports all the methods that Trait does.

3. Trait must be object safe

Unlike Haskell (iirc), there are some traits Trait (type classes) which can not be used in dyn Trait and thus existentially quantified and dynamically dispatched. Only those traits that are “object safe” may be used in this way, which means that Trait must satisfy the conditions enumerated in RFC 255.

4. Dynamically dispatched

Rust has two modes of existential quantification, one which uses static dispatch (-> impl Trait) and one which uses dynamic dispatch (dyn Trait). When we have Box<dyn Trait>, a vtable is created for each type T: Trait which contains pointers to the actual implementations of the methods in impl Trait for T (and other details…).

5. Boxed and lives on the heap

Because a Box is involved, the value lives on the heap.

On “dynamic type”

A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.

[…]

Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,” but the usage is standard

– Benjamin C. Pierce, Types and Programming Languages

Types do not exist at run-time since type systems are a syntactic method (there’s no syntax in this sense at run-time; you could argue that the bytes that make up the instructions themselves form a syntax, but this is not meaningful). A dynamically checked language like python is statically typed because it only has one type; so it is unityped. At the very least, if we are going to say that python is typed, then the types of python live in the same category as values in a language such as Rust or Haskell.

I believe that calling &(dyn Trait) a dynamic type only leads away from understanding; if we have x : &(dyn Trait), then x clearly has a type, which is &(dyn Trait).

In defense of Jargon

Jargon is a type of language that is used in a particular context and may not be well understood outside that context.

– https://en.wikipedia.org/wiki/Jargon

In any community or any field, it is only natural that there is some terms which are not well understood outside of the field. In Rust, we employ jargon such as:

• lifetime – Great and understandable jargon
• outlives – Inaccurate semantically
• trait object – Not accessible

The goal in communication is to find terms that:

1. do not lose semantic content / intent or precision;
2. are accessible and easy to comprehend for newcomers to the group and for people it.

Between these points, there exists a natural tension. In the effort to solve 2. you may lose critical information, and in an effort to preserve critical information, you may lose on accessibility. Thus, we should decide what is critical information, and what are details.

The problem is not jargon in general; it is bad jargon. We should try to find terms that strike a good balance between 1. and 2. but also tries to eat the cake and keeps it too.

[bbatha]

Yes! The type is constrained by a dynamic type parameter. I’d still call a &dyn Trait a dynamically typed reference where the fat pointer carries the run-time type information.

The point being that it is normal to take an object polymorphically constrained “by vtable” in most OOP languages. Users of those languages are going to hear “dynamic typing” and think no typing constraints what so ever, like the dynamic keyword in C# or pretty much every dynamic language’s type system. It would seem fortuitous to draw parallels between dyn Trait and interfaces in those languages when teaching Rust to folks coming from OOP backgrounds.

Moreover Box<dyn Trait>, &dyn Trait etc are concrete types at compile time; they are references to a dynamic type, not a reference of dynamic type. I suspect this distinction will be more important when Rust supports by value dyn Trait.

[steveklabnik]

and iirc it doesn’t show up anywhere in the book

We used the term “double pointer” rather than “fat pointer”, as it’s more descriptive. The latest draft doesn’t use the term at all, as we cut back on the details a bit.

[Centril]

We used the term “double pointer” rather than “fat pointer”, as it’s more descriptive. The latest draft doesn’t use the term at all, as we cut back on the details a bit.

Spitballing here (and it may totally be a bad idea), but how about:

• “annotated pointer”

[troiganto]

I’d like to voice my opinion in favor of renaming object-safe traits to “dyn-compatible traits”, as suggested by @bluss. It explicitly names the feature that it is enabling (so it’s also googlable) and “compatible”, while being longer than “capable”, definitely feels like a more common word to me as a non-native speaker.

I can see the advantage of annotating dyn-compatible traits and would like an (opt-in) lint on it. But, maybe due to lack of experience, I’m not seeing the problem that this annotation solves as so widespread that it justifies new syntax.

@kornel said they don’t like the attribute syntax because it feels like it’s used for complex or after-thought things, but I interpret most attributes as friendly advice to the compiler, but nothing that fundamentally changes the semantics of the annotated thing. (derive being the mandatory exception from the rule) As such, I’d prefer an attribute #[dyn_compatible] over any new syntax like dyn trait Trait {}.

[scottmcm]

+1 to “dynamic trait” sounds like a subset of traits, not of types.

the current way to [mark a trait as usable with dyn] is

trait Foo { ... }
fn assert_object_safe_foo(_: &Foo) {}

I think this is a great observation. Right now this is an important property that’s only noted with an arcane incantation. (And to emphasize how arcane, I think the above isn’t quite right, as it should be fn _assert_object_safe_foo to avoid “unused function” warnings.)

I quite like the notion of a warning that says “you used dyn on a trait that hasn’t promised to stay dyn-capable”. The logistics of making that not annoying sound difficult, but hopefully there are options. Especially given that there’s no (stable) code using dyn yet, so whatever it is could be tied to the dyn syntax rather than to the “trait object” concept.

(Sketch of one possibility: Rust 2018 implicitly adds #[dyn(never)] to traits that don’t have a dyn attribute, and supports that explicitly as well as #[dyn] for “dyn-safe”. Then when using dyn, you get the warning if the trait is #[dyn(never)] – which isn’t the case for unannotated traits in Rust 2015. And this extends naturally to potentially one day offering #[dyn(always)] that makes it usable only as a “trait object”, not as a bound.)

[Finn]

I’m much in favor of “dynamic type (of trait A)” and “polymorphic type (of trait A)” for dyn A. If Box is a mapping between types, then dyn A must be a type. One may see a type as a set/class of values (disjoint from all other types) and a set of operations supported on these values. Furthermore, dyn is a mapping that turns a type class A into the type dyn A. This type dyn A belongs to the static type system, and thus is statically typed, but its method access operator performs runtime dispatch. In this regard one may see dyn A as an interface between the static type system and a dynamic type system.

[Centril]

Furthermore, dyn is a mapping that turns a type class A into the type dyn A.

Yes, roughly the following mapping, as noted above (using Haskell notation and modulo memory representation, sizedness):

data Dyn (trait :: * -> Constraint) =
    forall (ty :: *). (trait ty :: Constraint) => Dyn ty

In this regard one may see dyn A as an interface between the static type system and a dynamic type system.

But there are no dynamic type systems (unless this refers to some dependently typed scheme where values refine types, but that is wholly different) as type systems are syntactic methods. The word static in static type system is therefore redundant.

As long as we qualify things as dynamic trait type, it feels OK to me, but dynamic type alone becomes misleading.

[felix.s]

// "There exists some `T: Trait`"
let x: Box<for<T: Trait> T>;

Doesn’t for denote universal quantification? (cf. for<'a> fn (&'a T) -> &'a U) There doesn’t seem to be a keyword for existential quantification yet.

[Centril]

Doesn’t for denote universal quantification?

An interesting question; and it does, as you can put any T inside of that Box so long as T: Trait.

However, the binder for<T: Trait> is not something you can apply any type to from outside the Box<T>, so operationally, if you were to pattern match on Box<for<T: Trait> T> (or use the methods of the type), you wouldn’t know which specific T it is. Instead, you only know that there is some T such that T: Trait.

So in this sense, Box::new is indeed universally quantified, but once that is done, and you have a Box<for<T: Trait> T>, there is no way to know what T it was anymore.

This is exactly what happens with Box<dyn Trait>, you can put any T: Trait you like in there, but once you’ve done that, you don’t know which T it was.

For more details, and probably better explanations, see:

• https://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types#A_Further_Explanation
• https://stackoverflow.com/questions/14299638/existential-vs-universally-quantified-types-in-haskell
• https://www.reddit.com/r/haskell/comments/32zjrm/existentiallyuniversally_quantified_types/
• http://abailly.github.io/posts/existential-types.html

[felix.s]

I know what you meant. I was just pointing out your choice of keyword was rather poor.

for<'a> fn (&'a u32) -> &'a u32 is a universally-quantified type: a holder of a value of that type can choose any concrete lifetime 'lt, obtain a fn (&'lt u32) -> &'lt u32 and call it.

By a similar token, 'I can put any T inside the Box’ can be understood as Box::new having type for<T> fn (T) -> Box<T> (although this is not a valid type in current Rust); whoever can access Box::new can choose a concrete type U and obtain a fn (U) -> Box<U>. (Inside the body of Box::new, however, T behaves like an existential type.)

One of the operations that can be done with such a Box<U> is moving out, which returns a U (assuming U: Sized). In particular, if U = for<T: Trait> T (which by some miracle is Sized), the owner of a Box<for <T: Trait> T> would get hold of a for<T: Trait> T, and should be able to choose any type T meeting Trait to obtain a value of that very type.

[felix.s]

As for the names themselves… given that the defining feature of dyn is dynamic dispatch, not so much ‘dynamic typing’ (however it is understood), why not refer to that? Call dyn Trait a 'dynamically-dispatched type, bound by Trait', while Trait itself can be called ‘dynamically dispatchable’ or ‘dynamizable’ whenever dyn Trait makes sense.

If you think ‘dynamically-dispatched type’ is too long, you need not use that name all the time. It can be shortened to just ’dyn type’ and everyone should still understand it.

[Centril]

I was just pointing out your choice of keyword was rather poor.

OK; that was not clear tho from your comment. I did a direct translation from Haskell; we could use exists<T> for clarity, but I wanted to be more faithful to the actual Haskell encoding of dyn. We do have for<'a> today, so it seemed a more natural and smaller delta

By a similar token, 'I can put any T inside the Box’ can be understood as Box::new having type for<T> fn (T) -> Box<T>

Indeed it can, as generic functions in both Rust and Haskell (both being based in various ways on System F) have explicit or implicit type lambdas which correspond to the for<T> quantifiers.

One of the operations that can be done with such a Box<U> is moving out, which returns a U (assuming U: Sized). In particular, if U = for<T: Trait> T (which by some miracle is Sized), the owner of a Box<for <T: Trait> T> would get hold of a for<T: Trait> T, and should be able to choose any type T meeting Trait to obtain a value of that very type.

My goal was not to set down a semantics of what Box<for<T: Trait> T> exactly means here… Only to illustrate how dyn is existential quantification and what it would correspond to in Haskell. Your comments about being able to get out a for<T: Trait> T sounds to me as more related to RankNTypes than ExistentialQuantification. The compiler would of course need to ensure that you are not able to get out a universally quantified for<T: Trait> T, from which the user can pick any T from, to preserve soundness (which is what dyn Trait does). In retrospect, perhaps Box<exists<T: Trait> T> would have been clearer to distinguish between these concepts.

If you think ‘dynamically-dispatched type’ is too long, you need not use that name all the time. It can be shortened to just ’dyn type’ and everyone should still understand it.

That seems OK.

[Centril]

Elaborating more on why I think “dynamically dispatched trait type” is the best proposal so far, let’s start with a maximally descriptive and unambiguous phrasing:

Box<dyn Foo> is a boxed, dynamically dispatched, existential type supporting the operations of the trait Foo.

This is quite packed with theory, so we try to eliminate extraneous details. The language informs us on what is important by having the dyn keyword as a syntactic cue.

Box<dyn Foo> is a (boxed), dynamically dispatched, (existential) type (supporting the operations of the) trait (Foo).

And so we get:

Box<dyn Foo> is a dynamically dispatched type […] trait.

We reorder to get a proper sentence:

Box<dyn Foo> is a dynamically dispatched (trait) type.

The term is somewhat long, but I believe it preserves the most important details whilst removing the, in the context of teaching dyn Trait, contextually less important aspects. Removing more details such as “trait” or “dispatched” becomes too ambiguous. As @felix.s suggested, but slightly modified here, we can shorten this to dyn trait type when among a more expert audience.

[Binero]

As opposed to adding a directive #[dyn_capable], could we not just have a marker trait like Send or Sync?

trait DynTrait: Dynamic {}

This could be automatically inferred as well, but the warning would appear if it’s not specifically said to require Dynamic.

I’m not a fan of new syntax as it can get confusing quickly when you have too much of it.

[theotherjimmy]

How about “trait-constrained reference”, “trait-constrained box”? “trait-constrained reference” emphasizes the fact that the reference must implement the trait.

[bbatha]

How about “trait-constrained reference”, “trait-constrained box”? “trait-constrained reference” emphasizes the fact that the reference must implement the trait.

With RFC 1909 we will be able to take some dyn types by value. The “trait-constrained X” terminology starts to get really confusing with values because traditional generics are already “trait-constrained”. Additionally, I think its important the the phrase we use at least have the word “dynamic” in it to match the keyword.

[theotherjimmy]

The “trait-constrained X” terminology starts to get really confusing with values because traditional generics are already “trait-constrained”. Additionally, I think its important the the phrase we use at least have the word “dynamic” in it to match the keyword.

How about “dynamic generics” as opposed to “static generics”? I personally find “dynamic types” to be too easily confused with dynamic typing.

Edit: as in “dynamic generic type” for dyn Foo, “dynamic generic reference” for & Foo, etc. where trait Foo . Further, for<T: Foo> T would be a “static generic type” and for<T: Foo> & Foo a “static generic reference” and both imply monomorphisation.

[scottmcm]

How about “dynamic generics” as opposed to “static generics”?

We already have lifetime generics and type generics, and will soon have const generics, all of which are static, so personally I’d like to avoid using “generics” for anything that isn’t static.

[nikomatsakis]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.