Thanks for noticing; It moved to https://tour.val-lang.dev/ so people could comment. We’ll add a redirect.
1 Like
We acknowledge as much (see the language tour).
@implicitcopyis Copy
No, really, it isn't. Rust's Copy is a trait that describes a subset of types that can be (in the judgement of the type's author) cheaply copied. Val's @implicitcopy is a directive that you can turn on for all types. We recognize copyability as a fundamental capability not related to performance, and unlike Rust we don't change the behavior of code based on whether passed arguments conform to this trait.
The other most significant differences with Rust are:
- We (believe we) have no confounding “borrow checker experience” for users (this of course remains to be proven). We can report issues primarily in terms of missing copies for copyable types.
- We have no named lifetimes (a source of great complexity in Rust), and yet
- we can safely express many things that can only be expressed in safe Rust by using named lifetimes.
- We never implicitly copy (unless you opt in with the directive).
- It is arguable that Rust presents a reference-based mental model, with additional uniqueness and immutability guarantees. We present a value-based mental model. Yes, you could claim they amount to the same thing in the end. We hope what we've got is easier and simpler to think about.
My one point of confusion is Sinkable. What’s an example of a type that is not Sinkable? Is that a “move-never” type?
Some special types might need to be pinned in memory, but the most common reason for unsinkability is that a type contains a stored inout or let projection. For example, a slice of a collection would store a projection of that collection and would be unsinkable, so that it never outlives the projected collection.
[FWIW, as I work on Val I find myself thinking much less often of “moving” things and more of “sinking” (a.k.a. consuming) them. It may be that “moving” ends up not being a very useful mental model in the end.]
19 Likes