[rust-dev] Misc questions and ideas

Michael Neumann mneumann at ntecs.de
Sun Dec 23 07:43:55 PST 2012


I've spent the last days hacking in Rust and a few questions and ideas
have accumulated over that time.

* If I use unique ~pointers, there is absolutely no runtime overhead,
  so neither ref-counting nor GC is involved, right?

* Heap-allocated pointers incur ref-counting. So when I pass a
  @pointer, I will basically pass a

    struct heap_ptr {ptr: *byte, cnt: uint}

  around. Right?

* vec::build_sized() somehow seems to be pretty slow. When I use it,
  instead of a for() loop, my rust-msgpack library slows down by 
  factor 2 for loading msgpack data.

  Also, I would have expected that vec::build_sized() will call my
  supplied function "n" times. IMHO the name is little bit
  misleading here.

* I do not fully understand the warning of the following script:

  fn main() {
    let bytes =

  t2.rs:2:14: 2:78 warning: instantiating copy type parameter with a not
  implicitly copyable type t2.rs:2   let bytes =

  Does it mean that it will copy the ~str again? When I use pattern
  matching instead of get(), I don't get this warning, but it seems to
  be slower. Will it just silence the warning???

* This is also strange to me:

  fn nowarn(bytes: &[u8]) {}

  fn main() {
    let bytes = ~[1,2,3];
    let br = io::BytesReader { bytes: bytes, pos: 0 }; // FAILS

  t.rs:6:36: 6:41 error: mismatched types: expected `&/[u8]` but found
  `~[u8]` ([] storage differs: expected & but found ~) t.rs:6   let br =
  io::BytesReader { bytes: bytes, pos: 0 }; ^~~~~

  It implicitly converts the ~pointer into a borrowed pointer when
  calling the function, but the same does not work when using the
  BytesReader struct. I think, I should use a make_bytes_reader
  function, but I didn't found one.

* String literals seem to be not immutable. Is that right. That means
  they are always "heap" allocated. I wished they were immutable, so
  that writing ~"my string" is stored in read-only memory.

  I never thought this would be possible:

  let s = ~"my string";
  let mut s2 = s;
  s2[0] = 'c' as u8;

  Is there a way how a function which takes a ~str can state that it
  will not modify the content?

  In this regard I very much like the way the D language handles this.
  It uses "const" to state that it won't modify the value, while the
  value itself may be mutable. Then there is "immutable", and a value
  declared as such will not change during the whole lifetime. 

  Of course in Rust, thanks to unique pointers, there is less need for
  immutability, as you cannot share a unique pointer between threads.

* Appending to strings. It's easy to push an element to an array by

  let mut v: ~[int] = ~[1,2];

  But when I want to append to a string, I have to write:

  let mut s: ~str = ~"";
  let mut s = str::append(s, "abc");
  let mut s = str::append(s, "def");

  I found this a bit counter-intuitive. I know there exists "+=", but
  this will always create a new string. A "<<" operator would be really
  nice to append to strings (or to arrays).

* Default initializers for structs. Would be nice to specify them like:

  struct S {a: int = 4, b: int = 3};

  I know I can use the ".." notation, and this is very cool and more
  flexible, but I will have to type in a lot of code if the struct get
  pretty large.

  const DefaultS = S{a: 4, b: 3}; // imagine this has 100 fields :)
  let s = S{a: 4, ..DefaultS};

* Metaprogramming

  Given an arbitrary struct S {...} with some fields, it would be nice
  to somehow derive S.serialize and S.deserialize functions
  automatically. Are there any ideas how to do that? In C++ I use the
  preprocessor and templates for that. In D, thanks to
  compile-time-code-evaluation, I can write code that will introspect
  the struct during compile-time and then generate code.

  I guess I could write a macro like:

  define_ser_struct!(S, field1, int, field2, uint, ...)

  which would generate the struct S and two functions for
  serialization. Would that be possible with macros?

Thanks in advance,


More information about the Rust-dev mailing list