neroimage.blogg.se - Rust the method map exists but

#RUST THE METHOD MAP EXISTS BUT CODE#

mem::forget will take any value and prevent it from being Dropped. Assigning to a variable, printing it, stuffing it in collection, or even calling panic!() is no escape: drop() will be called.Īctually there’s one escape hatch: mem::forget(). For instance, printing a Step1Token or putting it in a collection will mark it as used for the purposes of these analyses.ĭrop provides stronger support for must-use values by introducing a final step that will automatically be called on a value as it’s destroyed. However in more complex scenarios it’s easy to accidentally mark the value as “used” without actually properly using it. Read() // WARNING: unused result which must be used let _ = read() // OKĪll of these together are generally good enough to remind users to call step2() after step1(), especially if step2 is usually immediately after step1. This is what Rust calls move semantics, or move-only types. Almost every type in Rust is Clone (or, at least, could be without any issue). Plain Old Data types like i32, f64, and are Copy. Copying a Clone value requires an explicit call to clone(), while destroying a Clone value implicitly calls drop(). incrementing and decrementing reference counts).Ĭlone is like Copy, but where we might need to do some work when we do the copy or destroy – like the aforementionned reference count manipulation.

#RUST THE METHOD MAP EXISTS BUT CODE#

This is in contrast to Swift and C++, which may implicitly execute code when a value is copied or destroyed (e.g. In Rust it has a very specific language semantic as well: copying the value can be done with a bitwise copy, and discarding the value can be done by just forgetting about it (it can’t implement Drop). Copy is the form we’re all used to: total unrestricted use of the value. Rust provides this semantic in two forms: Copy and Clone.

This one doesn’t really need any justification – it’s how basically every programming language works.

must be used at least once (relevant™ - this one is a decent name)Īlso for added confusion, sometimes linear™ or affine™ is used as a synonym for the whole substructural™ system.

can be used any number of times (no name - the default).

Because remember: the reason we make type systems is to help us solve actual problems.Īll the combinations of having-and-not-having these properties gives us 4 interesting kinds of type: The definition of use is purposefully vague here, because as you’ll see Rust plays around with “what is a use” a lot to make the type system do things we actually care about.

can be used more than once (contraction™).

can be used less than once (weakening™).

Two of them are interesting to us, and one of them we don’t care about. So this type system defines three operations that a (instance of a) type might support. As such, I’ll be providing all the “standard” names (and explaining where they get mixed up) with a Trademark of Disdain™ while otherwise favouring the more intuitive Rust-centric terminology. That said, academia and research exists independent of my terminology gripes. Therefore I’ve found it much more helpful to use a naming scheme that appeals to this intuition and avoids the muddied baggage of the old names. Substructural Type Systems are actually fairly simple things which are very easy to reason about intuitively. However I haven’t observed this duality to be actually helpful.

Yes, the names have a justification Substructural Types are the natural consequence of applying Substructural Logic to Type Theory. As in, I frequently see conversations about this topic quickly get muddied and confused because two people are using the same terms to mean different things. My experience from discussing this system and its application to Rust and other programming languages is that it’s poorly named, and so are most of the concepts it introduces. So there’s this thing called a Substructural Type System™, that Rust takes some ideas from.įirst off, I need to explain something about naming. I tried to explain it off the top of my head, but I figured it’s best for me to just write it out. For whatever reason “linear” types in Rust came up at work today, at which point I made my usual assertion that they’d be a nightmare to implement, because they don’t compose well.