Início / coding / Perguntas / 79542660
Accepted
JMA
Asked: 2025-03-29 09:21:16 +0800 CST

`T: Trait`/`impl Trait` não satisfaz `dyn Trait`, exceto quando o faz

  • 772

Eu encontrei um comportamento de variância estranho que tenho certeza de que é uma falha na minha compreensão do sistema de tipos, mas parece um bug do compilador.

trait Trait: 'static {}
impl<T> Trait for T where T: 'static {}

struct Inner<T>(T);

fn make_inner<T: Trait>(t: T) -> Inner<Box<T>> {
    Inner(Box::new(t))
}

type DynNecessary = Vec<Inner<Box<dyn Trait>>>;

struct DynCarrier {
  things: DynNecessary,
}

impl DynCarrier {
    pub fn spawn(&mut self, t: impl Trait + 'static) {
        let inner = make_inner(t);
        
        self.things.push(inner);
    }
}

fn main() {}

link do playground

No exemplo acima, make_innerrecebe Te retorna Inner<Box<T>>onde T é conhecido por satisfazer Trait.
No entanto, ao tentar usar o valor de retorno de make_inneralgum lugar que aceita Inner<Box<dyn Trait>>, obtenho o seguinte:

= note: expected struct `Inner<Box<(dyn Trait + 'static)>>`
           found struct `Inner<Box<impl Trait + 'static>>`

Eu tinha um palpite de que isso tinha algo a ver com a maneira como o programa em tempo de execução trataria um dyn Traitversus um concreto impl Trait, mas onde isso desmorona para mim é na seguinte mudança:

fn make_inner<T: Trait>(t: T) -> Inner<Box<dyn Trait>> {
    Inner(Box::new(t))
}

onde now té coagido com sucesso para dyn Trait.
Que influência a inferência de tipo de retorno tem sobre tipos, que a inferência de tipo de argumento não tem? Se .pushassume a propriedade de inner, por que não é capaz do mesmo tipo de coerção?

rust

1 respostas

  1. Best Answer

    A coisa a lembrar aqui é que dyn Trait é um tipo concreto . É um tipo concreto estranho , que por acaso compartilha sua representação na memória com muitos outros tipos, mas é um tipo. Box<dyn Trait>, portanto, também é um tipo concreto específico (com seu próprio layout particular na memória que inclui um ponteiro vtable).

    Na primeira versão do código, você está construindo um Inner<Box<T>>, onde Thá algum tipo implementando Trait(and T ≠ dyn Trait), e então tentando usá-lo onde Inner<Box<dyn Trait>>é esperado. Isso falha porque é uma incompatibilidade de tipos.

    Mas e quanto à coerção para dyn Trait? Por que isso não está acontecendo? Porque isso só acontece para tipos específicos de contenção . Especificamente, nas versões atuais do Rust (a maneira como é descrito pode mudar em versões futuras), você pode consultar o CoerceUnsizedtrait unstable para ver todos os tipos que podem ser coagidos dessa maneira. Note que Boxestá nesta lista — então você pode coagir Box<T>para Box<dyn Trait>— mas, claro, seu Innernão.

    Na segunda versão com -> Inner<Box<dyn Trait>>, o tipo de retorno declarado informa a inferência de tipo dentro make_inner()de tal forma que a construção de Inneré entendida como requerendo um parâmetro do tipo Box<dyn Trait>, e que a coerção é suportada. O princípio geral aqui é: a Box<T>deve ser coagido para a Box<dyn Trait> antes de você envolvê-lo em (quase) qualquer outra coisa . Definir o tipo de retorno é uma maneira de fazer isso acontecer.

    Uma demonstração, ou possivelmente uma solução alternativa útil, é que seu código original será compilado se você desmontá-lo e recriá-lo Innercom o tipo correto:

    let inner = make_inner(t);

let Inner(boxed) = inner;
let inner: Inner<Box<dyn Trait>> = Inner(boxed);

self.things.push(inner);

    Ou, se você estiver satisfeito em usar recursos instáveis, basta implementar CoerceUnsizede seu código funcionará sem outras alterações:

    #![feature(coerce_unsized)]

use std::ops::CoerceUnsized;

impl<T, U> CoerceUnsized<Inner<U>> for Inner<T> where T: CoerceUnsized<U> {}

    Quando isso implfor usado, Tserá igual ao Box<impl Trait>tipo e Userá igual a Box<dyn Trait>.

    No entanto, eu recomendaria a solução simples que você já encontrou: especifique Box<dyn Trait>com antecedência suficiente que a coerção aconteça no momento da construção.

    • 9

relate perguntas