8 ms·

I wrote you a little example but i think you need to know rust to really understand it :( https://is.gd/FlBCJ0 https://is.gd/FlBCJ0 you cannot uncomment the c

I wrote you a little example but i think you need to know rust to really understand it :( https://is.gd/FlBCJ0 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/ownership.html https://doc.rust-lang.org/book/references-and-borrowing.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/ownership/ http://intorust.com/tutorial/shared-borrows/ http://intorust.com/tutorial/shared-borrows/

Anderkent 10y ago
This is really cool, thanks!
saosebastiao 10y ago
Can you explain the purpose of your '_unconstructable'?
- icen 10y ago
  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.
- lordnaikon 10y ago
  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-constructors-in-rust http://words.steveklabnik.com/structure-literals-vs-construc...
- Tarean 10y ago
  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 };
estefan 10y ago
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?
- tom_mellior 10y ago
  > 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-making-illegal-states-unrepresentable/ http://fsharpforfunandprofit.com/posts/designing-with-types-... (This particular post is F#, but the idea is general.)
  - estefan 10y ago
    > 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.
- dbaupp 10y ago

Anderkent 10y ago

This is really cool, thanks!

saosebastiao 10y ago

Can you explain the purpose of your '_unconstructable'?

icen 10y ago
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.
lordnaikon 10y ago
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-constructors-in-rust http://words.steveklabnik.com/structure-literals-vs-construc...
Tarean 10y ago
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 };

estefan 10y ago

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?

tom_mellior 10y ago
> 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-making-illegal-states-unrepresentable/ http://fsharpforfunandprofit.com/posts/designing-with-types-... (This particular post is F#, but the idea is general.)
- estefan 10y ago
  > 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.
dbaupp 10y ago