I wrote you a little example but i think you need to know rust to really understand it :(

https://is.gd/FlBCJ0

you cannot uncomment the comments in the main function and use it wrong, the compiler prevents you to compile this code.

these two sections from the book may help understad this

https://doc.rust-lang.org/book/ownership.html

https://doc.rust-lang.org/book/references-and-borrowing.html

if you're more into videos this may help

http://intorust.com/tutorial/ownership/

http://intorust.com/tutorial/shared-borrows/

Nice example. I was learning Rust over Christmas so I see how it works. But one issue I have is that from the outside it's not obvious that your `close()` method will take ownership of `self`. I'd probably prefer it if there was some (compiler-enforced) convention that made it obvious to clients that `close()` would consume `self`.

As it stands, Rust code can break the principle of least surprise, since what happens in a method can affect the associated instance variable (in this case `open_socket`). A user could easily write several lines of code and only discover that `open_socket` has been moved into a method at compile-time.

I found myself having very small coding-compile iterations when writing in Rust to catch issues like this (but that was also undoubtedly due to the fact I was learning).

Is there a pro tip to avoid this issue?

> it's not obvious that your `close()` method will take ownership of `self`

I'm in the middle of reading the Rust book right now, so this may be dumb, but... Isn't this exactly the point of using a naked `self` instead of the reference `&self`? If it's not a reference, `self` is consumed by the method. At least that's my current understanding

If you mean that the one-character difference is very small for such an important semantic distinction, I might agree.

As for the state machine example, I like it a lot as well. It's very similar to the idea of "making illegal states unrepresentable" from the OCaml world: http://fsharpforfunandprofit.com/posts/designing-with-types-... (This particular post is F#, but the idea is general.)

> Isn't this exactly the point of using a naked `self` instead of the reference `&self`?

Yes it is, but you only see it's a naked self if you look into the method. From the outside there's nothing in the name to indicate that it doesn't take a reference. So potentially it means that for every method call you need to check that it takes a reference to `self` instead of ownership. This would be especially annoying with third-party libraries.

The alternative in other languages is the error (using a socket that has been closed/resource that has been semantically moved away) is only found at runtime. The compiler flagging a mistake like this exactly the point of having the compiler and is a great example of how Rust helps defend against mistakes. Compiling early and compiling often is a great way to develop, IME.

In Rust, I personally don't think about moving vs. not until the compiler tells me I have to, because it usually doesn't matter. Rust previously required moves to be explicitly marked, but it wasn't worth it in practice: http://smallcultfollowing.com/babysteps/blog/2012/10/01/move... (see "Wait, doesn’t this make it hard to know what your program does?" in particular.)

Can you explain the purpose of your '_unconstructable'?

Sure. It is a private field(no pub) preventing you from constructing that type with a literal. It is of type "unit" '()' so it does not add up space for the type. "unit" has only one value that makes it "zero-sized". because i did not supply an "constructor" to that type it is not constructable outside the module and can only created by types in the scope of the enclosing module. Its more or less a private constructor known in C++/Java ... etc.

Steve Klabnik has a more complete write up regarding this http://words.steveklabnik.com/structure-literals-vs-construc...

If a struct is public, and all its members are public, you can just create a new instance of the struct with braces (in that case, it would be `OpenSocket { data: 12 }` - or whatever value you like), not what is necessarily correct. By having a hidden zero sized struct member, you need to use the library's api to construct them.

It is basically a hack to export the type but not the type constructor. It stops people from doing things like

    let new_socket = OpenSocket { port: 12 };

This is really cool, thanks!

Example: http://insanitybit.github.io/2016/05/30/beyond-memory-safety...

TL;DR: compile time checking that your state machine transition is correct.

Thanks, I'll take a look.

It ensures that you consume a state at most once. You can kind of visualize state 'moving' through your functions - going in through the arguments and out through the returned value.