Criação de tempo de execução: String não encontrada neste escopo

Dec 18 2020

Um problema comum que os desenvolvedores de substrato podem enfrentar: desenvolver um palete personalizado para armazenar o mapeamento em tipos comuns, como String. Como um exemplo:

#[derive(Encode, Decode, Clone, Default, RuntimeDebug)]
pub struct ClusterMetadata {
    ip_address: String,
    namespace: String,
    whitelisted_ips: String,
}

Ao criar o tempo de execução, você obtém este erro para cada String:

     |
  21 |     ip_address: String,
     |                 ^^^^^^ not found in this scope

Por que Stringsnão estão incluídos no escopo? E outros stdtipos de ferrugem?

Respostas

4 ShawnTabrizi Dec 18 2020 at 07:35

O erro aqui não está relacionado a no_std, então provavelmente você só precisa importar o Stringtipo para obter os erros reais com o uso de strings no tempo de execução.

O verdadeiro problema que você encontrará é que Stringnão é codificável pelo Parity SCALE Codec, que é obviamente um requisito para qualquer item de armazenamento (ou quase qualquer tipo que você deseja usar) no tempo de execução.

Portanto, a questão é "Por que SCALE não codifica String"?

Isso é por escolha. Em geral, Stringé um tipo surpreendentemente complexo. O livro Rust passa uma seção inteira falando sobre as complexidades do tipo.

Como tal, ele pode facilmente se tornar uma arma de fogo dentro do ambiente de execução que as pessoas usam Stringincorretamente.

Além disso, geralmente é uma prática ruim armazenar Strings no armazenamento em tempo de execução. Acho que podemos concordar facilmente que minimizar o uso de armazenamento no tempo de execução é uma prática recomendada e, portanto, você só deve colocar em itens de armazenamento que você precisa para ser capaz de derivar consenso e transições de estado em seu tempo de execução. Na maioria das vezes, os Stringdados seriam usados ​​para metadados e esse tipo de uso não é a prática recomendada.

Se você olhar mais de perto o Substrato, verá que quebramos essa prática recomendada mais de uma vez, mas esta é uma decisão que tomamos explicitamente, tendo as informações em mãos para podermos avaliar corretamente o custo / benefício.

Tudo isso combinado é porque Strings não são tratados como um objeto de primeira classe no tempo de execução. Em vez disso, pedimos aos usuários que codifiquem strings em bytes e, em vez disso, trabalhem com essa matriz de bytes.