Concrete consequence of impl absence?

1

Hi,
Reading this page: https://doc.rust-lang.org/rust-by-example/fn/methods.html

Is it possible to embed the implementation in the sub?
What are the practical consequences?
Larger build time?

Thanks

2

What is a "sub"?

If you are meaning "put the methods inside the struct definition like other languages" then the biggest reasons to have impl blocks separate from the struct declaration are

  • Visually separating a type's data and its behaviour make you think and approach things differently
  • I can have multiple impl blocks
  • For generic types, it lets me write impl blocks which add methods to my struct which only make sense for under certain circumstances (e.g. say I have a N-dimensional point, struct Point<T, const N: usize>([T; N]), I might want to add a method for the dot product when N is 2... impl<T: Add+Mul> Point<T, 2> { fn dot(...) -> T { ... } })
  • You aren't constrained to having your type and all its methods and all its interface implementations written in the same file

The difference is almost entirely related to developer ergonomics, and it doesn't impact build times nearly as much as other decisions the Rust language designers made (monomorphisation, macros, type system is turing complete, etc.).

2 Likes
3

I feel really sorry, I wrote on a smartphone and didn't see the mistake.

I meant struct.

In C++ it has implications on Translation Units ==> longer building times.

So if Rust doesn't have this limitation, that's a good thing..

Thanks!

This language is starting to make sense

4

FYI: in Rust the compilation unit is an entire crate.

The compiler can reuse some work when recompiling a crate ("incremental compilation") but for the most part, how you organize code within a crate will not affect the characteristics of the compilation process.

4 Likes
5

Wow, that's great news actually.

Really, really good

6

Yeah, it makes different trade-offs with different pros/cons.

For example, it means importing code from a different module has no effect on build times other than adding another entry to your "current namespace" hashmap. It also means you don't need to re-parse and re-typecheck the definition for a struct for every file in your project that uses it.

However, it does mean changing one file means you need to rebuild the entire crate, although this is largely offset by the awesome work done by the Rust compiler team to cache all the fine-grained analysis and object files generated from previous runs.

7

Do you mean that if a crate imports 10 modules and I do only change one of them, I could have to rebuild the whole crate, except if the compiler detects that changes only occurred in that file and only recompile that module?

8

Have a look at the "Queries" section in the rustc dev guide - it details how the Rust compiler is implemented internally much better than I could explain in a single post.

1 Like
9

Thanks for the pointer Michael, I will read it now.

10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.