Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deriving Traits in Rust with Procedural Macros

naftuli.wtf

Post reply on HN
Print view View original

11–20 of 31 posts

Re: Deriving Traits in Rust with Procedural Macros

#11

Post by eridius »

throwmeawayjj wrote: post #7
sierdolij wrote: post #3

Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope. Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption. There seems to be a need for training classes in Rust that…

> I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. By default the value is moved in Rust, just like with std::move in C++17, which you say you know. This is to avoid performance issues when you pass complex structures, such as vectors, around. If you want to copy your value, you have to call .co…

Well, .clone()

Re: Deriving Traits in Rust with Procedural Macros

#12

Post by sierdolij »

throwmeawayjj wrote: post #7
sierdolij wrote: post #3

Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope. Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption. There seems to be a need for training classes in Rust that…

> I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. By default the value is moved in Rust, just like with std::move in C++17, which you say you know. This is to avoid performance issues when you pass complex structures, such as vectors, around. If you want to copy your value, you have to call .co…

First: Grow up throw-away account, you don't need to add FUD know-it-all, jackassism. It's uncivilized and substance-free. You can sign up under a legitimate handle and behave along the intended guidelines, or go somewhere else.

That explains the move but not mandating explicit verbosity for a common case. Pony, for example, has consume to end the lifetime of a variable, .

Re: Deriving Traits in Rust with Procedural Macros

#13

Post by atoav »

shmerl wrote: post #10
bpicolo wrote: post #6

Earlier quoted context omitted.

Procedural macros are something you more or less never need to write in application code, but they add tremendous power to libraries

Which doesn't make it easier, since you might want to structure part of you application code as a reusable library.

It is entirely optional. I use Rust for two years now and work on a few things (biggest one around 10kLOC). I didn’t even read the Macro section in my books yet. Because I didn’t need to.

Re: Deriving Traits in Rust with Procedural Macros

#14

Post by pornel »

sierdolij wrote: post #3

Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope. Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption. There seems to be a need for training classes in Rust that…

Rust doesn't have syntax for passing by value vs passing by reference. The syntax you're thinking of is instead for lending vs moving, e.g. moving `Box` is still passing values by reference (but owned), and `&str` is a small copyable struct passed by value (but borrowed).

It's not the surprise-copy-horror you'd expect, because there are no copy constructors, and nothing large is ever copied implicitly (you have to call `.clone()` or implement `Copy` trait for a type).

The move semantics can ensure there exists only one owning pointer to each object. It can be statically known who owns the object, and most importantly, who has to free it.

Re: Deriving Traits in Rust with Procedural Macros

#15

Post by microtonal »

a1369209993 wrote: post #8
sierdolij wrote: post #3

Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope. Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption. There seems to be a need for training classes in Rust that…

> Borrowing The way I think about this (which isn't quite how rust seems to) is that every value (including references) is always destroyed by passing it to a function, but gets implicitly copied if (arg is copyable && arg is referenced below). Eg: T a = mkT() # create value foo(&a) # create and immediately destroy/pass reference bar(a) # => bar(copy(&a)) # create-and-pass copy baz(a) # last use, so dont bother copyi…

is always destroyed by passing it to a function, but gets implicitly copied if (arg is copyable && arg is referenced below)

I am not sure what you are trying to say. This:

  bar(a) # => bar(copy(&a)) # create-and-pass copy
  baz(a) # last use, so dont bother copying
is not possible in Rust if a's type is not a copy type. a will be moved when calling bar, so trying to pass it to baz will result in a compiler error.

The story is quite simple: a value is always moved in a function call, unless it is a copy type (the type implements the Copy trait). When the type is a copy type, a bit-wise copy is made. References are not special: immutable references are copy types. Mutable references are not copy types (otherwise, they could be aliased).

You can find an overview of all copy types in the standard library in the implementations section of the Copy trait:

https://doc.rust-lang.org/beta/std/marker/trait.Copy.html#fo...

Re: Deriving Traits in Rust with Procedural Macros

#16

Post by lmm »

bpicolo wrote: post #6
insertcredit wrote: post #2

Rust is morphing into a complexity beast that rivals C++. When the cognitive load require to read and write Rust code far exceeds that required of other, more popular languages, the future does not look rosy.

Procedural macros are something you more or less never need to write in application code, but they add tremendous power to libraries

Deriving typeclass implementations is something I do all the time in regular application code (in Scala), once you're used to it it gives you a lot of safety and expressive power. It sounds like Rust would benefit from some kind of record system / generic representation of traits (like we get from Shapeless in Scala) so that generic trait deriving could be written in normal code without needing macros.

Re: Deriving Traits in Rust with Procedural Macros

#17

Post by keldaris »

atoav wrote: post #13
shmerl wrote: post #10

Earlier quoted context omitted.

Which doesn't make it easier, since you might want to structure part of you application code as a reusable library.

It is entirely optional. I use Rust for two years now and work on a few things (biggest one around 10kLOC). I didn’t even read the Macro section in my books yet. Because I didn’t need to.

Most of the complexity of C++ is entirely optional too. That doesn't make the observation any less valid.

Re: Deriving Traits in Rust with Procedural Macros

#18

Post by microtonal »

insertcredit wrote: post #2

Rust is morphing into a complexity beast that rivals C++. When the cognitive load require to read and write Rust code far exceeds that required of other, more popular languages, the future does not look rosy.

This may be true, but is not a very constructive comment without pointing out which language features or interactions between language features you find complex.

Ownership and the borrows checker may have a steep learning curve, but are not very complex. The rules are quite simple, the learning curve is steep because most programmers do not typically think about ownership (though they should).

(In my experience in teaching Rust, things like trait impl coherency rules, object safety, and finding a good balance between static and dynamic polymorphism are much harder for students than understanding the ownership system.)

Re: Deriving Traits in Rust with Procedural Macros

#19

Post by dbaupp »

sierdolij wrote: post #3

Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope. Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption. There seems to be a need for training classes in Rust that…

> Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope.

In Rust there's a move or a falling out of scope. Lifetimes are passive, and just describe the connection between references so that the compiler can check that they don't become dangling when values are destroyed in essentially the same places as C++ would destroy them.

> Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption.

Rust had a more pony-like model with annotations and different modes many years ago, but the model was unnecessarily complicated and was simplified to a "everything is pass-by-value" one:

- http://smallcultfollowing.com/babysteps/blog/2011/12/08/why-...

- http://smallcultfollowing.com/babysteps/blog/2012/10/01/move...

Things to know:

- Rust has no copy constructors (but does have a "this can be safely semantically duplicated by memcpy" marker trait (Copy), which cannot run arbitrary code. See https://stackoverflow.com/a/31013156/1256624 and https://stackoverflow.com/a/24253573/1256624.)

- A "move" is a memcpy (bitwise copy) of a value to a new location, where the source becomes inaccessible at compile time

- A "read-only" T is a separate type &T, which is a value in its own right (and &_ implements Copy, so can be passed-by-value multiple times without explicit copies).

- Every value of type T is always a fully-fledged T, with all of T's operations available

- Parameters of type T (e.g. fn f(x: T)) are thus full values

- For an arbitrary type T, there's no way to (implicitly) copy values of type T, so the only way to call a function with a T parameter is to have the callee take ownership/responsibility for the caller's T value (i.e. move it into the call)

Re: Deriving Traits in Rust with Procedural Macros

#20

Post by papaf »

lmm wrote: post #16
bpicolo wrote: post #6

Earlier quoted context omitted.

Procedural macros are something you more or less never need to write in application code, but they add tremendous power to libraries

Deriving typeclass implementations is something I do all the time in regular application code (in Scala), once you're used to it it gives you a lot of safety and expressive power. It sounds like Rust would benefit from some kind of record system / generic representation of traits (like we get from Shapeless in Scala) so that generic trait deriving could be written in normal code without needing macros.

Isn't Shapeless based in macros?

That said, an equivalent library in Rust would be very useful.

Post reply on HN