Re: [rust-dev] Why explicit named lifetimes?

On 22.05.2014 17:54, Felix S. Klock II wrote: Michael (cc'ing rust-dev)- On 22 May 2014, at 16:32, Michael Woerister wrote: Lately I've been thinking that it might be nice if one could omit the lifetimes from the list of generic parameters, as in: fn foo(x: &'a T, y: &a

Re: [rust-dev] Why explicit named lifetimes?

On 19/05/14 20:52, Brian Anderson wrote: On 05/15/2014 09:30 PM, Tommi wrote: On 2014-05-16, at 7:14, Daniel Micay wrote: On 16/05/14 12:10 AM, Tommi wrote: I was just wondering, why do we have to explicitly specify the lifetimes of references returned from functions? Couldn't the compiler

Re: [rust-dev] Using gdb on rust

Hi Ricardo, lldb should work OK with Rust executables. The error you mention should be solved by also specifying the file containing the line you want to break in. So instead of writing just `b -l 5`, try `b -l 5 -f main.rs` instead (specifying the correct source filename, of course). The comma

Re: [rust-dev] Debugging : traversing code in libraries (rust 0.10 release)

If the extern crate is compiled with debug symbols, this should just work. Unfortunately, I don't think there is a 'configure' setting for enabling debug symbols for librand and the other 'post-extra' crates yet. It might be worth filing an issue for. Using --disable-optimize is not strictly nec

Re: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?)

If I had any spare time left I'd love to work on something like this. Kudos for giving this a try! On 13.03.2014 08:50, Phil Dawes wrote: FWIW I've started working on autocomplete functionality for rust. https://github.com/phildawes/racer I'm persuing the 'scan the source code text, incremental

Re: [rust-dev] RFC: Stronger aliasing guarantees about mutable borrows

I'm all for it. In fact, I thought the proposed new rules *already* where the case :-) On 25.02.2014 19:32, Niko Matsakis wrote: I wrote up an RFC. Posted on my blog at: http://smallcultfollowing.com/babysteps/blog/2014/02/25/rust-rfc-stronger-guarantees-for-mutable-borrows/ Inlined here: T

Re: [rust-dev] Debugging (rust 0.9) in Ubuntu via GDB

Hi, the `break` command can be a bit particular where function names are concerned, especially when namespaces and generics are involved. The correct full name of the shuffle method would be something like `std::rand::TaskRng::shuffle` (there is a seperate function for every set of concrete ty

Re: [rust-dev] Persistent data structures

On 05.12.2013 16:59, Bill Myers wrote: No, the problem you describe does not exist in my implementation because it requires an &mut to the smart pointer. You are right. I needed some time to wrap my head around this :) This is really a very clever approach! I'm looking forward to experimenting

Re: [rust-dev] Persistent data structures

On 05.12.2013 03:15, Bill Myers wrote: The reason I introduced COW when RC > 1 is that it allows persistent data structures to be mutated in place if there aren't extra references, just like non-persistent data structures. That's a great idea that an might obviate the need to have a separate `B

Re: [rust-dev] Persistent data structures

Is it possible for the structure to be parametrized on smart pointer? Not without higher kinded types (which eventually we do want--so the answer is "not yet"). I've been thinking about that a bit more and I think it might be possible to support different reference types without higher-kinde

Re: [rust-dev] Persistent data structures

For reference, the FromIterator & Extendable traits are the things to implement if one has a structure that can be constructed from/extended with an iterator and wishes to share the behaviour. http://static.rust-lang.org/doc/master/std/iter/trait.FromIterator.html http://static.rust-lang.org

Re: [rust-dev] Persistent data structures

I've implemented a persistent HAMT [1] a while back: https://github.com/michaelwoerister/rs-persistent-datastructures/blob/master/hamt.rs It's the data structure used for persistent maps in Clojure (and Scala, I think). It's not too hard to implement and it's pretty nifty. I'm not sure about th

Re: [rust-dev] Placement new and the loss of `new` to keywords

+1 for `expr @ place` On 02.12.2013 11:57, Kevin Ballard wrote: With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr@place` -Kevin Ballard __

Re: [rust-dev] Rust's newest full-time Engineer

Hi Alex, I too applied for the position and after reading through some of your pull requests and comments mid-August I remember thinking to myself "man, I hope that guy hasn't applied too" :P Your work is awesome! Congratulations :) Cheers, Michael On 16.09.2013 22:43, Alex Crichton wrote:

Re: [rust-dev] map on range generates internal compiler error

On 08/16/2013 06:32 AM, Huon Wilson wrote: On 16/08/13 11:33, Amitava Shee wrote: I am getting the following error - is this a bug? amitava:learn amitava$ cat app.rs // vi:ts=4:sw=4:nu fn main() { range(1u,3).map(|_| 5); } amitava:learn amitava$ make rustc -Z debug-info -o

Re: [rust-dev] Iterator blocks (yield)

On 11.08.2013 15:25, Benjamin Striegel wrote: Note that we have an issue open in the bug tracker for this: https://github.com/mozilla/rust/issues/7746 Sorry for not replying to this earlier. Thanks for the hint! I have read the discussion in the issue and tried to take it into account in my wr

Re: [rust-dev] Iterator blocks (yield)

On 12.08.2013 21:19, Graydon Hoare wrote: I'm happy to reserve 'yield' as a keyword for future experiments, but I don't think we have either scope or a coherent enough design to commit to doing anything particular with it at the moment. We're generally trying to get all the things we have semi-wo

Re: [rust-dev] rustdoc_ng: 95% done

On 08/12/2013 05:33 PM, Corey Richardson wrote: Hello all, I present to you: rustdoc_ng http://seld.be/rustdoc/master/index.html It's basically done, only a few minor bugs remain, as well as the listing of `pub use`'s. I've been using it as my only doc browser the past day and it's quite wonder

Re: [rust-dev] Iterator blocks (yield)

Hi, [...] The reason I'm bringing this up is because in case Rust ever wants to gain support for bidirectional generators it should from the very start have something like a "yield from" to not break the reverse forwarding. Thanks for the extensive explanation. These iterators with bi-directio

Re: [rust-dev] Iterator blocks (yield)

On 11.08.2013 12:31, Matthieu Monrocq wrote: I cannot comment on the difficulty of implementation, however I can only join Armin in wishing that if it ever takes off it would be better to make the declaration explicit rather than having to parse the definition of the function to suddenly realiz

Re: [rust-dev] Iterator blocks (yield)

On 11.08.2013 12:01, Armin Ronacher wrote: The way "yield return" works in C# is that it rewrites the code into a state machine behind the scenes. It essentially generates a helper class that encapsulates all the state. In Rust that's much harder to do due to the type system. Imagine you ar

Re: [rust-dev] Adding "else" on "for" loops, like Python

On 08/10/2013 07:24 PM, Paul Nathan wrote: On 8/10/13 7:10 AM, Simon Sapin wrote: Hi, Now that the for loop is based on external iterators, can we reconsider "for-else"? Proposal: for i in iter { // ... } else { // ... } The optional else block is executed wh

[rust-dev] Iterator blocks (yield)

Hi everyone, I'm writing a series of blog posts about a possible *yield statement* for Rust. I just published the article that warrants some discussion and I'd really like to hear what you all think about the things therein: http://michaelwoerister.github.io/2013/08/10/iterator-blocks-features.

Re: [rust-dev] Removing codemap::spanned

On 07/26/2013 06:18 PM, Patrick Walton wrote: On 7/26/13 8:54 AM, Michael Woerister wrote: To me this seems very much like a slightly clunky way of emulating inheritance (with a lot more typing involved at definition and usage sites). Field accessor functions or traits can alleviate some of

Re: [rust-dev] Removing codemap::spanned

Reviving an old thread here because I'm still working on this. I suspect you'll want to make a trait `Spanned` that the various spanned-types implement, such that code that generically acts on "Some spanned thing" can continue to work. Not sure, just a hunch. I thought so too, but after removing

Re: [rust-dev] 'in' for for loops and alloc exprs

> for : { ... } -1. The `:` symbol is already hugely overloaded, and it's less readable to boot. I think `for : { ... }` reads a lot like `for *of type* { ... }`, which doesn't make much sense. `for in { ... }`, on the other hand, looks very nice. _

Re: [rust-dev] Removing codemap::spanned

On 15.07.2013 19:34, Patrick Walton wrote: On 7/15/13 12:39 AM, Michael Woerister wrote: Thinking about it, side table or not, the spanned struct would go away in its current form anyway, right? So it should be a step in the right direction, to gradually remove its usages. Since spanned affects

Re: [rust-dev] Removing codemap::spanned

On 13.07.2013 18:25, Patrick Walton wrote: On 7/13/13 7:27 AM, Michael Woerister wrote: So, I thought it might be a good idea if I tried to remove the spanned struct altogether and added the span field directly to the types that are wrapped at the moment. If needed, I would also add a Spanned

[rust-dev] Removing codemap::spanned

Hi everyone, I want to help clean up the Rust codebase and one thing I stumbled across a few times in the last weeks is the 'spanned' generic struct from libsyntax::codemap: pub struct spanned { node: T, span: span } It is used quite often to conveniently add a span field to types in libsynt

[rust-dev] mk_t() and interning in middle/ty.rs

Hi, I hope this question is not too specific for the mailing list, but I stumbled upon something I don't understand today and thought I'd better ask. In librustc/middle/ty.rs there is the mk_t() function which creates and caches objects of type "t" from values of type "sty". However, the way it

Re: [rust-dev] Memory layout of types

On 06/24/2013 07:28 PM, Graydon Hoare wrote: On 13-06-24 09:10 AM, Michael Woerister wrote: This still leaves open the question of internal runtime structures, such as heap boxes, vecs, and possibly pointers. Unsafe and region pointers seem to be regular machine-word sized values, but I think

Re: [rust-dev] Memory layout of types

On 06/24/2013 05:26 PM, Patrick Walton wrote: On 6/24/13 2:14 AM, Michael Woerister wrote: * There is the trans::adt module and the Repr enum which look very promising. It does not provide all the information I need (e.g. it will include generated fields, but does not explicitely specify where

[rust-dev] Memory layout of types

Hi everyone! As you may know, I'm working on debug info support for rustc. Last week I found a small bug regarding the size of structs as stored in the debug info. Once found, it was not hard to fix but it led me to thinking a bit more on how to handle memory layout in the debug info code and h