Reminds me of Coq's definition of `False`:<p>`Inductive False := .`<p>i.e., `False` has no constructors and hence is an empty type.<p>Anyway, this means that for any type `A`, you can construct a function of type `False -> A` because you just do this:<p>`fun (x : False) => match x with end.`<p>Since `False` has no constructors, a match statement on a value of type `False` has no cases to match on, and you're done. (Coq's type system requires a case for each constructor of the type of the thing being matched on.) This is why, if you assume something that is false, you can prove anything. :)
I get the feeling this doesn't really get into the meat of what "drop" is. It seems you can't really explain why you "love" a function without discussing its purpose. Maybe I'm wrong, I'm only really an outsider looking in when it comes to rust, but it does fascinate me as far as its goals. I would go so far as to say that it will be important for systems programmers to know in the not too distant future (if it's not already).<p>Isn't it really only there in case someone needs to "hook into" the drop functionality before the variable is dropped? Please correct me if I'm wrong.<p>EDIT: Minor editing to clarify meaning.
I wouldn't say std::mem::drop acts like free at all, it's the equivalent of a destructor in C++. Mostly useful when you're dealing with manually allocated memory, FFI, implementing an RAII pattern, etc.<p>One cool thing about Drop (and some other cool stuff, like MaybeUninit) is that it makes doing things like allocating/freeing in place just like any other Rust code. There may be some unsafe involved, but the syntax is consistent. Whereas in C++ seeing placement new and manually called destructors can raise eyebrows.
I haven't used rust, so can you explain this to me:<p>If I do the rust equivalent of:<p><pre><code> def add1(x):
return x + 1
x = 1
y = add1(x)
z = add1(x)
</code></pre>
then will x have been deallocated by the first call to add1 and will the second call to add1 fail?<p>[You can ignore the fact that I'm using numbers and substitute an object if that makes more sense in the context of allocating / deallocating memory in rust.]
Sometimes Rust programmers write this same function as a closure, which can be known as the 'toilet closure'[1]:<p><pre><code> |_| ()
</code></pre>
[1] <a href="https://twitter.com/myrrlyn/status/1156577337204465664" rel="nofollow">https://twitter.com/myrrlyn/status/1156577337204465664</a>
Do variables go out of scope after last use or when the function exits? I could see the former evolving into the language if it’s not already the default behavior.<p>In which case there’s only one situation where I could see this useful, and that’s when you are building a large object to replace an old one.<p>The semantics of<p><pre><code> foo = buildGiantBoject();
</code></pre>
In most languages is that foo exists until reassigned. When the object represents a nontrivial amount of memory, and you don’t have fallback behavior that keeps the old data, then you might see something like<p><pre><code> drop(foo);
foo = buildGiantBoject();
</code></pre>
Most of the rest of the time it’s not worth the hassle.
> Now this might seem like a hack, but it really is not. Most languages would either ask the programmers to explicitly call free() or implicitly call a magic runtime.deallocate() within a complex garbage collector.<p>The compiler actually implicitly adds drop glue to all dropped variables!
For me, rust is still love & hate, even after 1 year of half-time (most of the free time I have) hacking.<p>It's a wonderful language but there are still some PITAs. For example you can't initialize some const x: SomeStruct with a function call. Also, zero-cost abstraction is likely the biggest bullshit I've ever heard, there is a <i></i>lot<i></i> of cost and there's also a lot of waiting for compiler if you're using cargo packages.<p>That said, I wouldn't rather use C/C++/Go/Reason/Ocaml/? - that is probably the love part.<p>BTW: I've recently stopped worrying about unsafe and it got a bit better.<p>So my message is probably:
- keep your deps shallow, don't be afraid to implement something yourself
- if you get pissed off, try again later (sometimes try it the rust way, sometimes just do it in an entirely different way)
<p><pre><code> let x = String::from("abc");
std::mem::drop(&x);
std::mem::drop(&x);
std::mem::drop(&x);
std::mem::drop(&x);</code></pre>
can someone elaborate on this passage:<p>The beauty of programming language design is not building the most complex edifice like Scala or making the language unacceptably crippled like Go - but giving the programmer the ability to represent complex ideas elegantly and safely. Rust really shines in that regard.<p>i'm fairly ignorant on the various differences but my general feeling was that Go is quite useful?
Gotta admit, that really is a cute example. However, I was a bit surprised when the author described Go as "unacceptably crippled." What is he referring to?
> or making the language unacceptably crippled like Go<p>Gotta say, I lost a lot of respect for the author at this point. It’s not like I don’t love Rust - quite the contrary - but if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight. Go has been one of my languages of choice for over half a decade now, and for good reason.