3 ms·

Less magic is such a good value to have. You can always make magic from unmagic pieces, but it's not possible to de-magic-ify magic. For example, I really dug

• pjmlp 12y ago
  Having a GC as a library type means many optimizations that need compiler help are not possible unless the library types are "magic" to the compiler.
  • kibwen 12y ago
    Even if the GC were in the language, the optimizations that you speak of would have negative performance ramifications on all code that did not use GC. The reason that we took the plunge and moved GC into the stdlib was because we weren't willing to make that sacrifice. It does mean that our GC will never be particularly optimal. And that's fine, because if you really need shared ownership you should be using our really great refcounted pointers instead. :)
    • pjmlp 12y ago
      I used to agree with Rust approach, assuming the compiler does dataflow analysis to minimize needless refcounting. Now that the refcounting is also moved to a library, I am not sure. Or are those types known to the compiler and the respective optimizations applied?
      • dbaupp 12y ago
        They fall out automatically from move semantics, a reference count only occurs on an explicit clone call: fn just_a_ref(x: &T) { ... } fn rc_by_val(x: Rc<T>) { ... } fn rc_by_ref(x: &Rc<T>) { ... } let some_rc_pointer: Rc<T> = ...; just_a_ref(&*some_rc_pointer); // no ref counting rc_by_ref(&some_rc_pointer); // no ref counting rc_by_val(some_rc_pointer.clone()); // ref count incremented // last use of a value (statically guaranteed that // some_rc_pointer is never used again): rc_by_val(some_rc_pointer); // no ref counting
        • pjmlp 12y ago
          Thanks for the clarification.