Entrevista de Rust: ¿Cómo agregar límites Send a futuros de traits async con return type notation?

Planteamiento y alcance

Mantienes un trait Service utilizado por diferentes ejecutores. Sus métodos usan async fn, pero solo algunos puntos de llamada pasan un Future a una tarea que puede moverse entre hilos. Explica por qué declarar cada Future devuelto como Send es demasiado restrictivo y proporciona reglas de selección para return type notation (RTN), una variante de trait y un GAT.

La pregunta se enfoca en AFIT y RPITIT estabilizados en Rust 1.75 y RTN propuesto por el RFC 3654. RTN sigue siendo un experimento en nightly; separa la capacidad del lenguaje, los requisitos del ejecutor y la estabilidad de la versión en tu respuesta.

Qué está evaluando el entrevistador

Una respuesta sólida identifica cada Future como un tipo de retorno anónimo de un método de trait. Las personas que llaman genéricas o con dyn Trait no pueden inferir su propiedad Send solo a partir del trait, por lo que el límite pertenece al punto de llamada que realmente cruza hilos.

El entrevistador también espera el alcance de RTN: restringe los valores de retorno de AFIT/RPITIT en lugar de actuar como un tipo de campo ordinario. Analiza el riesgo de nightly, los ejecutores de un solo hilo, los ejecutores con work-stealing y las rutas de compatibilidad.

Preguntas aclaratorias

¿Puede el Future moverse entre hilos?

Si el ejecutor fija el trabajo a un solo hilo, Send puede ser innecesario. Un ejecutor con work-stealing necesita que un Future generado sea Send, y comúnmente también requiere 'static.

¿El límite es para un método o para todo el trait?

Si solo call debe ser movible, RTN puede expresar call(..): Send. Si cada método necesita el mismo límite, una variante de trait evita repetir cláusulas a nivel de método.

¿Se puede usar nightly en producción?

Si una biblioteca pública debe admitir Rust estable, RTN no puede ser el único diseño. Evalúa un trait Send generado o un GAT explícito y registra las versiones del compilador en la matriz de versiones.

Una respuesta en 30 segundos

“Primero verifico si el ejecutor puede mover tareas y qué métodos necesitan esa garantía. Mantengo el trait base con restricciones mínimas y luego escribo T::call(..): Send + 'static en el punto de llamada que genera tareas a través de hilos. Si cada método necesita Send, uso una variante de trait; si se requieren Rust estable y un Future con nombre, uso un GAT. RTN está en nightly, por lo que lo probaría en una cadena de herramientas aislada y mantendría una alternativa estable.”

Solución paso a paso

Paso 1: Derivar límites a partir del ejecutor

Un ejecutor de un solo hilo o de un hilo por núcleo generalmente no mueve tareas entre hilos. Un ejecutor con work-stealing sí lo hace, por lo que un Future pasado a spawn normalmente necesita Send y a menudo 'static. Por lo tanto, Send es un requisito del consumidor, no una propiedad predeterminada de cada método de trait.

Paso 2: Restringir un método con RTN

RTN agrega límites al tipo devuelto por un método. Lo siguiente utiliza sintaxis de nightly:

trait Service<Request> {
    type Response;
    async fn call(&self, request: Request) -> Self::Response;
}

async fn spawn_call<S, R>(service: S, request: R) -> S::Response
where
    S: Service<R> + Send + 'static,
    R: Send + 'static,
    S::call(..): Send + 'static,
{
    tokio::spawn(async move { service.call(request).await })
        .await
        .expect("task failed")
}

S::call(..) se refiere al Future devuelto por el método del trait, no al valor producido después de esperarlo (await). Restringe únicamente a los consumidores que necesitan la propiedad y deja las implementaciones locales utilizables en otros lugares.

Paso 3: Comparar una variante de trait

Cuando cada método async necesita Send, mantén un trait base con restricciones mínimas y genera una variante Send:

#[trait_variant::make(SendService: Send)]
trait LocalService<R> {
    async fn call(&self, request: R) -> Response;
}

Esto se adapta a una API pública con una ruta común: los implementadores apuntan a un trait base y quienes llaman eligen la variante local o Send. La desventaja es una menor precisión a nivel de método; RTN es mejor cuando solo un método necesita el límite.

Paso 4: Elegir un GAT cuando nombrarlo de forma estable es importante

Si Rust estable debe nombrar el Future devuelto, un GAT puede exponer un tipo asociado:

trait StableService {
    type Future<'a>: Future<Output = Response> + Send + 'a
    where
        Self: 'a;
    fn call(&self) -> Self::Future<'_>;
}

Cada implementación debe proporcionar un tipo Future concreto, lo que aumenta el código repetitivo (boilerplate). Utiliza esto cuando el soporte estable y el almacenamiento o la reutilización del tipo Future superen la ergonomía de la sintaxis async.

Paso 5: Validar limitaciones y riesgos de migración

El equipo de Rust documenta que RTN se aplica a funciones asociadas de traits o métodos que usan AFIT/RPITIT; actualmente no se puede usar como un tipo de campo de struct. Prueba la sintaxis, los diagnósticos y la expansión de macros en CI con nightly, mientras preservas una ruta de variante de trait o GAT para versiones estables.

Paso 6: Convertir la comparación en una regla

Elige RTN para un requisito de cruce de hilos a nivel de método y de punto de llamada; una variante de trait cuando todos los métodos compartan el requisito; y un GAT cuando Rust estable y un tipo de retorno nombrable sean obligatorios. Si el ejecutor nunca mueve una tarea, conserva el Future local en lugar de reducir el conjunto de implementaciones por una supuesta seguridad.

Respuesta modelo de alta calidad

Primero pregunto si el ejecutor puede mover una tarea. Con un ejecutor con work-stealing como Tokio, el Future externo generado generalmente necesita Send + 'static; con un ejecutor de un solo hilo, propagar ese límite a cada implementación es innecesario. Mantengo el trait base mínimo y escribo S::call(..): Send + 'static solo en la función genérica que cruza hilos. Eso preserva las implementaciones cuyo Future de call es únicamente local.

Si cada método async debe ser movible, uso una variante de trait para ofrecer una API Send. Si el proyecto debe permanecer en Rust estable y necesita nombrar o almacenar el Future, uso un GAT. RTN todavía está en nightly, por lo que lo aíslo en CI y mantengo el diseño estable en lugar de hacer que la sintaxis experimental sea la versión mínima pública.

Errores comunes

• Síntoma → Agregar Send a cada retorno async en el trait → Por qué falla → Se excluyen implementaciones válidas de un solo hilo → Solución → Colocar el límite en el consumidor que cruza hilos.
• Síntoma → Tratar S::call(..) como el tipo de resultado esperado con await → Por qué falla → RTN limita el Future devuelto, no S::Response → Solución → Expresar la distinción explícitamente.
• Síntoma → Enviar RTN de nightly directamente a producción → Por qué falla → El compilador y el soporte sintáctico pueden cambiar → Solución → Fijar la versión nightly en CI y mantener una alternativa estable.
• Síntoma → Convertir cada async trait a un GAT → Por qué falla → Los implementadores deben exponer tipos Future concretos → Solución → Usar GAT solo cuando el nombrado estable sea un requisito real.
• Síntoma → Comprobar únicamente si Service es Send → Por qué falla → Un servicio movible aún puede devolver un Future que no sea Send → Solución → Limitar el objeto, los argumentos, el Future devuelto y la tarea externa por separado.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué S: Send no es suficiente para S::call(..): Send?

S: Send indica que el valor del servicio puede moverse entre hilos. Su método aún puede capturar Rc u otro valor no Send dentro del Future. Una generación entre hilos verifica el Future externo y cada Future esperado con await, por lo que el Future devuelto necesita su propio límite.

Pregunta de seguimiento 2: Solo put necesita Send mientras que get utiliza una caché local. ¿Qué haces?

Mantén el trait base y restringe el put(..): Send del Backend en el punto de llamada que cruza hilos. No generes una variante que también restrinja get, porque eso rechazaría una implementación válida de caché local.

Pregunta de seguimiento 3: RTN aún no puede ser un tipo de campo. ¿Cómo puedes almacenar el Future?

Usa un GAT explícito, un Future con nombre o bórralo en el límite con Box::pin. Elige según el soporte estable, el costo de asignación y las necesidades de object-safety; RTN no crea automáticamente un tipo almacenable.

Pregunta de seguimiento 4: ¿Cómo demuestras que los límites no son demasiado estrictos?

Escribe tres casos de compilación: una implementación local que carece de Send pero se ejecuta en un hilo; una implementación donde solo put devuelve un Future Send; y una donde cada método se puede generar a través de hilos. Ejecuta cada uno en estable y nightly y verifica que los fallos ocurran en el punto de llamada previsto.