Enfin !
That library was largely written by "bjorn3", a Rust compiler team member who contributed more than 3,000 of the approximately 4,000 commits to Rust's Cranelift backend.
Not all heros wear capes.
— Permalink
if if if a == b {
b == c
} else {
a == c
} {
a == d
} else {
c == d
} {
println!("True!");
} else {
println!("False!");
}
]]>
xD
— Permalink
In tuto sympa surserde
(parce que autant les fonctionnalités de serde-derive
sont ergonomiques et plutôt bien documentées, autant la partie manuelle c'est moins évident.
Edit: sur serde-derive
Mick m'a appris ça:
#[serde(try_from = "&[u8]")]
pub struct Signature(
#[serde(serialize_with = "<[_]>::serialize")] [u8; LENGTH],
Comme serde
ne supporte pas les const-generics
il est limité aux tableaux de 32 éléments de long, mais l'invocation du dessus permet de contourner le problème:
]]>serde does not support const generics yet and so ser/deser is only implemented for [T; N] where N <= 32.
try_from uses a TryFrom implementation to deserialize.
serializewith = "<[]>::serialize" uses the slice serialization implementation instead of the fixed length array.
Très bonne source pour entrainer/guider un LLM pour la transcription de C en Rust.
— Permalink
C'est intéressant: c'est un langage qui s'intéresse à la sureté mémoire spatiale, là où le borrow-checker s'intéresse à la sureté mémoire temporelle. (voir cet article sur les différences entre les deux)
C'est intéressant, parce que la sureté mémoire spatiale a longtemps été considéré comme un problème moins gênant que la sureté temporelle, parce qu'on pouvait faire des vérifications à l'exécution pour pas cher, là où pour l'aspect temporel le coût en performance (garbage collector) était prohibitif pour plein d'applications.
Mais quand le “borrow-checker” de Rust est arrivé, on s'est rendu compte qu'on pouvait avoir la sureté temporelle sans impact sur les perfs, alors que la sureté spatiale impliquait un (léger mais substantiel) coût à l'exécution.
— Permalink
Content de voir qu'il existe une lib pour faire ça !
— Permalink
Pas vraiment convaincu par cet argument, c'est plus un argument contre la notation .
pour les méthodes, parce que ça peut arriver aussi si tu as des méthodes qui ne sont pas des méthodes de traits qui sont en commun entre deux types. Et pour autant personne n'échangerait le obj.methode()
contre la forme Type::methode(obj)
(qui est par ailleurs supportée en Rust).
— Permalink
I have no idea what the complexities and caveates of doing this would be, but it could also be interesting to have the crate publishing step do aggressive borrow checking logic for every supported platform but then disable the borrow checker on crates downloaded from crates.io. The borrow checker contributes a lot of time to the compilation process, and if you gate acceptance to crates.io on the borrow checker passing then you can get away without needing to run the extra borrow checker logic when compiling dependencies.
Ça c'est vraiment pas très malin, pour plein de raison: déjà parce que le borrow-checker ne prend pas tant de temps que ça, ensuite parce qu'il arrive après les phases cfg resolution (quelque soit son nom réel) de “macro expansion”, donc ce n'est pas vraiment possible en pratique, ou plutot ça revient au même que de stocker des versions pré-compilées des dépendances sur crates.io.
— Permalink
Ce qui devait arriver arriva. J'aimerai beaucoup que cargo soit sandboxé par défaut …
— Permalink
Le plus triste dans cette histoire c'est que des gens vont se mettre à verrouiller leur dépendance à serde
sur une version en particulier, ce qui va conduire à une montagne de problème (bien plus grands que le problème initial, qu'il s'agisse du temps de compilation ou du fait d'avoir une dépendance sous forme de binaire).
La vraie solution serait d'avoir cargo
qui supporte nativement ce genre de chose (idéalement via webassembly comme dtolnay l'avait proposé il y a plusieurs années)
— Permalink