Início / coding / Perguntas / 79221451
Accepted
cher-nov
Asked: 2024-11-25 10:19:57 +0800 CST

Por que restringir o tipo de unidade por uma característica genérica vinculada a uma cláusula where (como em `where () : Trait<…>`)?

  • 772

Hoje encontrei aqui uma sintaxe um tanto estranha - where ():
https://github.com/binator/self/tree/80ba2ade?tab=readme-ov-file#example

fn hex_primary<Stream, Context>(stream: Stream) -> Parsed<u8, Stream, Context>
where
  (): IntRadixParse<Stream, Context, u8>,
{
  uint_radix(2, Radix::HEX).parse(stream)
}

Para mim parece "limitado ao tipo unitário (também conhecido como tupla vazia )", mas não consigo entender. Um tipo unitário não implementa todas as características por padrão, certo? Infelizmente, a documentação oficial é muito vaga e não é completa o suficiente (ao mesmo tempo em que é excessivamente prolixa), e não consegui encontrar nada relacionado nela.

A cláusula RFC for original wheretambém menciona essa sintaxe, mas sem explicação adequada:
https://rust-lang.github.io/rfcs/0135-where.html#alternatives

fn increment<T>(c: T) -> T
    where () : Add<int,T,T>
{
    1 + c
}

Mas além disso, eu sei que tais limites podem ser especificados não apenas em genéricos de traits.
Então o que é, quando é usado, por que é necessário e quais problemas ele resolve?

generics

2 respostas

  1. Best Answer

    No trecho de código, a wherecláusula é usada para restringir as restrições genéricas. Em vez de definir todas as restrições, (): IntRadixParse<Stream, Context, u8>é usada, o que significa que qualquer tipo Streame Contexttêm, eles devem seguir as restrições de IntRadixParse.

    O traço IntRadixParseé

    pub trait IntRadixParse<Stream, Context, Token: 'static> = where
  Stream: Streaming,
  <Stream as Streaming>::Item: Into<u8>,
  Token: CheckedAdd + CheckedMul + CheckedSub + Zero + Copy + Debug,
  Context: Contexting<IntRadixAtom<Token>>,
  Context: Contexting<BaseAtom<u8>>,
  Context: Contexting<CoreAtom<Stream>>,
  Context: Contexting<UtilsAtom<Stream>>,
  u8: AsPrimitive<Token>;

    Nota: Ele usa o recurso de alias de traço instável

    Então, para escrever a função sem a estranha sintaxe de restrição de unidade, seria algo como

    fn hex_primary<Stream, Context>(stream: Stream) -> Parsed<u8, Stream, Context>
where
  Stream: Streaming,
  <Stream as Streaming>::Item: Into<u8>,
  Context: Contexting<IntRadixAtom<u8>>,
  Context: Contexting<BaseAtom<u8>>,
  Context: Contexting<CoreAtom<Stream>>,
  Context: Contexting<UtilsAtom<Stream>>,
{
  uint_radix(2, Radix::HEX).parse(stream)
}

    Nota: Na função Tokenfoi substituído poru8

    Outro exemplo :

    #![feature(trait_alias)]

trait A<T> = where T: B; // Similar to `IntRadixParse` which
                         // shows that T should implement B

/// trait B with a method a
trait B {
    fn a(self);
}

/// implemented for unit
impl B for () {
    fn a(self) {}
}

fn a<T>(a: T) where (): A<T> {
    a.a() // T gets inferred to have implemented B and `a()` can be called
}

fn main() {}
    • 6

  2. (): IntRadixParse<Stream, Context, u8>realmente é um limite no tipo de unidade. Funciona porque o alias de trait 1 é definido assim:

    pub trait IntRadixParse<Stream, Context, Token: 'static> = where
    …; // where bounds omitted for brevity

    Observe especialmente a característica ausente antes de where, não há característica, então este é um alias para nenhuma característica, dadas as condições.

    Cada tipo preenche "implementa um conjunto vazio de características", então a única coisa que resta a ser provada pelo compilador são os limites. Então, resumindo, como Selfnão é referenciado e não há nenhuma característica para ele preencher, em vez de unit ()você pode escrever qualquer tipo lá. Quando o tipo não importa, os programadores Rust geralmente usam unit.

    Isso torna os aliases de características úteis para abreviar um monte de limites, como explicado na resposta de Timsib Adnap

    1. aliases de características são instáveis
    • 6

relate perguntas