Re: [rust-dev] Avoiding borrow check assertions with @mut

I had a similar problem when writing an iterator for a tree-like data structure. The iterator held a stack (vector) of per-node iterators and needed to push into it while accessing the last node. In my case the whole thing works with owned and burrowed pointers. I managed to implement the immutabl

Re: [rust-dev] Avoiding borrow check assertions with @mut

Here is the heart of the code, maybe it will be clearer why I had to use unsafe (or, maybe, how I could avoid it): /// A path is just an array of atoms. #[deriving(Eq, TotalEq, Ord, TotalOrd, Clone, IterBytes)] pub struct Path { /// The array of atoms the path consists of. pub atoms: ~[Ato

Re: [rust-dev] Avoiding borrow check assertions with @mut

Thanks for all the responses! I knew there was something simple I could do in my specific case - in this case, `.take()` or more generically `utils::replace`. Thanks for the pointers. That said, the general problem remains. I think it goes as follows: - There is a container accessible from some

Re: [rust-dev] cycle time, compile/test performance

Perhaps this is a crazy idea, but why not use SQLite or some similar efficient DB format to store the meta-data? This isn't a "quick fix", of course, but on the face of it it should provide efficiency improvements in accessing just what one needs, plus the potential for enabling an ecosystem of ana

[rust-dev] Dynamic in Rust

tion` container, which holds key/value pairs where whoever sets a value knows its type, whoever gets the value should ask for the same type, and the configuration can hold values of "any" type - not from a predefined list of types). Is such a thing possible, and if so, how? Thanks, Oren

Re: [rust-dev] Dynamic in Rust

ion and declare these types there. On Fri, Aug 23, 2013 at 7:54 AM, Abhijeet Gaiha wrote: > You could define an enum that encapsulates all known types. > > enum monster { > Integer(int), > Float(float), > > } > > Then use a container for this type.

Re: [rust-dev] Dynamic in Rust

ll doubtless break when we change the > vtable format. The real question is what you can do with the type > descriptor; they are not canonicalized, after all. Still, it's > ... very close. This is basically how dynamic downcasting would work, > in any case. > > > Niko

Re: [rust-dev] Dynamic in Rust

goes through hoops > to check those things), but it is doable if sufficient information is > encoded in the v-table. > > > On Fri, Aug 23, 2013 at 5:04 PM, Oren Ben-Kiki wrote: > >> Yes, this would be similar to the `Typeable` type class in Haskell. It >> queries t

Re: [rust-dev] Dynamic in Rust

Yes, Rust has a `deriving` attribute one can attach to types (for stuff like `Eq`, `Ord`, etc.). That said, as long as the vtable is already there, I think Rust should do what Haskell is moving to (automatically `derive Typeable`) - that is, automatically place the necessary data in the vtable. H

Re: [rust-dev] Dynamic in Rust

a syntax error on the `int` or `T`. On Fri, Aug 23, 2013 at 8:50 PM, Graydon Hoare wrote: > On 13-08-23 09:49 AM, Oren Ben-Kiki wrote: > > Yes, Rust has a `deriving` attribute one can attach to types (for stuff > > like `Eq`, `Ord`, etc.). > > > > That said, as lo

Re: [rust-dev] Dynamic in Rust

! On Fri, Aug 23, 2013 at 9:15 PM, Graydon Hoare wrote: > On 13-08-23 11:08 AM, Oren Ben-Kiki wrote: > > Interesting - I see std::intrinsics::unstable::get_tydescr -> > *TyDescr... > > > > Two questions: > > > > - Can this be used for a quick type equality c

Re: [rust-dev] Doc comment conventions + straw poll

I prefer using /// for comments before functions and types, and ///! for comments following fields: /// ... pub struct Foo { foo: int, //! ... } (BTW, it would be nice to document function arguments: /// ... pub fn foo( foo: int, //! ... ) { ... } But rustdoc doesn't have the concept

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

I just tested this in my code, it solved a sticky problem I had with updating owned data nested deep inside a tree-ish container. My original solution wasn't very nice (it just compromised on efficiency and copied too much data around). The new code is shorter and more efficient (no copies! yey!).

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

Sigh, I guess it was too good to be true :-( I'd settle for the ability to say: update_in_place(foo.owned_pointer, &fn(~T) -> ~T) - surely this would be safe? Speaking of which, a secondary problem I encountered when doing this sort of thing, is the "Once function" issue listed in https://github.

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

Since swap seems to have its own problems - would it be possible to tweak the stealing idea so the compiler would know there's a burrowed mutable pointer to the hole, effectively preventing further access to it in the vulnerable block? I really would like to be able to use this approach, it really

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

Another thought on this. Currently, either the compiler is satisfies that the code is 100% safe, or we slap an "unsafe" keyword around the code and put 100% of the responsibility on the programmer, with no support from the Rust system. Wouldn't it make sense to have a "not statically safe, but ver

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

ined behavior" and make good use of knowledge that any such access will, in fact, fault, on any machine I might be coding to today. On Sat, Sep 7, 2013 at 6:55 PM, Patrick Walton wrote: > On 9/7/13 8:39 AM, Oren Ben-Kiki wrote: > >> I have a feeling that there is a non-trivial

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

ep 7, 2013 at 7:20 PM, Daniel Micay wrote: > On Sat, Sep 7, 2013 at 12:09 PM, Oren Ben-Kiki wrote: > >> If in practice on any machine today (X86, ARM, PowerPC, MIPS, SPARC, ...) >> every null pointer will fault (which I strongly hope will...), then I'd be >> quite ha

Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity

tandard, it is *designed* to take full advantage of that fact when making > optimizations. In other words, all hell will break lose, in potentially > very complicated and subtle ways. > > Geoffrey > > On Sep 7, 2013, at 1:22 PM, Daniel Micay wrote: > > > On Sat, Sep 7, 201

Re: [rust-dev] Type parameters in trait bounds

Rust newbie here as well, trying to develop an intuition for these things myself :-) Off the top of my head - you are saying the map holds entries whose lifetime is 'input; but there's no guarantee that the map lifetime itself wouldn't be longer than that. Try saying &'input M instead of &M and see

Re: [rust-dev] RFC: Syntax for "raw" string literals

Just to make sure - how does the C++ syntax behave in the presence of line breaks? Specifically, what does it do with leading (and trailing) white space of each line? My guess is that they would be included in the string, is that correct? At any rate, having some sort of here documents would be ve

Re: [rust-dev] rusti - the - repl renovation

Would running test-to-destruction cases that are expected to fail count as "running in a sandbox"? Currently I spawn them to a separate task and catch its failure, which is probably better practice - but it would be nice if I were able to access the message given to fail and compare it with the exp

Re: [rust-dev] Struct members in trait definitions

How about allowing anonymous fields, like go does? It seems to provide most of the benefits at very little language complexity cost. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Struct members in trait definitions

AFAIK the go solution walks a thin line here. An anonymous field means one can directly access any subfield, and also that the container has all the included struct traits - as implemented by the included struct. It is also possible to override the implementation. This is different from what was a

[rust-dev] If and pattern match

_foo), Some(_bar)) => true, _otherwise => false, } } So, in general allow `pattern ~~ expression` to be a boolean expression and if it is used in an "if" statement allow it to introduce the matched variables to the "then" scope. The operator doesn't

Re: [rust-dev] If and pattern match

I agree that is a macro like your `if_matches` examples were possible, it would be a reasonable solution, including conferring the right scope for `a` and `b`. It is completely unclear to me how to implement it though. What does "use_more_macros line" mean? Thanks, Oren. On Mon, Sep 23, 2013

Re: [rust-dev] Some suggestions of Rust language

On Wed, Sep 25, 2013 at 6:29 PM, Patrick Walton wrote: > On 9/25/13 6:32 AM, Alexander Sun wrote: > >> Embedded anonymous structure? >> > Embedded anonymous structure in Go is good idea, I think. >> > > Not the way Go does it, where you can have method conflicts like C++ > multiple inheritance an

Re: [rust-dev] Should we add a Haskell-like `$` operator?

Not sure about $ but I sometimes miss the |> operator (which takes the value from the left and inserts it as the 1st argument of the function call to the right). foo(a, b) |> bar(c, d) |> baz(e, f) == baz(bar(foo(a, b), c, d), e, f) This allows for easier "functional" decompsition of chains of op

Re: [rust-dev] Should we add a Haskell-like `$` operator?

Not sure about $ but I sometimes miss the |> operator (which takes the value from the left and inserts it as the 1st argument of the function call to the right). foo(a, b) |> bar(c, d) |> baz(e, f) == baz(bar(foo(a, b), c, d), e, f) This allows for easier "functional" decompsition of chains of op

Re: [rust-dev] Should we add a Haskell-like `$` operator?

Not sure about $ but I sometimes miss the |> operator (which takes the value from the left and inserts it as the 1st argument of the function call to the right). foo(a, b) |> bar(c, d) |> baz(e, f) == baz(bar(foo(a, b), c, d), e, f) This allows for easier "functional" decompsition of chains of op

Re: [rust-dev] Should we add a Haskell-like `$` operator?

Right, the simple left-to-right chaining is why I thought that |> might be a good fit for Rust - foo |> bar means exactly do foo and then bar. On Sep 26, 2013 7:21 PM, "Jeff Petkau" wrote: > I don't think the problem with '$' is that it's infix; it's that it makes > the data flow read right-to-le

Re: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation

Ok, color me confused... perhaps there's somewhere that explains 'self on more detail? For example, _why_ does the example below not work without the explicit <'self>? It seems like it should. I have yet to truly understand the whole 'self thing. When I first read about lifetimes, my naive expecta

Re: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation

gt; r_int: &'self int > } > > s: MyStruct<'a> > > then lifetime_of(s) <= 'a && lifetime_of(s.r_int) <= 'a. (Which is trivial > because lifetime_of(s) == lifetime_of(s.r_int).) > > Basically, every object has a lifetime - from i

Re: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation

t a lot of reasonable, safe, useful code. On Mon, Sep 30, 2013 at 12:13 AM, Gábor Lehel wrote: > > `On Sun, Sep 29, 2013 at 9:21 PM, Oren Ben-Kiki wrote: > >> Thanks for the explanation. You said two key points: >> - Basically, every object has a lifetime - from its

Re: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation

Huh, this is _exactly_ my use case. I have data structures which I grow but never shrink, and I never move anything out of them. This idiom isn't that uncommon when writing in functional style... I incrementally build a complex structure that allows quick access to the same pieces using different

Re: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation

arily suggest @'heap as a syntax, but you get the idea) Gc would still run in the context of one heap at a time... but this would remove the restriction of one task <=> one heap. On Mon, Sep 30, 2013 at 1:17 PM, Gábor Lehel wrote: > On Mon, Sep 30, 2013 at 8:31 AM, Oren Ben-Kiki

Re: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation

hance of writing code that actually works :-) Thanks for the explanations! On Mon, Sep 30, 2013 at 5:34 PM, Steven Blenkinsop wrote: > On Monday, 30 September 2013, Oren Ben-Kiki wrote: > >> Yes, it is very much like an arena... And yes, the idea is that all the >> pointers are con

Re: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation

That's good! But there remains the fact that there's no way to say "my lifetime is the same as the struct that contains me". If 'self specialness goes away, perhaps it can be re-introduced to mean that (or a different name can be given to it). On Mon, Sep 30, 2013 at 7:01 PM, Benjamin Striegel wr

[rust-dev] The new format!

I just transitioned my code to use the new format! macros. I was happy to get rid of all the .to_str() I had all over the place, but this turned out not quite as I had expected. I was hoping I'd be able to simply base on the ToStr trait to print anything with {:s}. It turns out that actually there

Re: [rust-dev] The new format!

though. I guess I'd still have to litter my code with lots of .to_str() when printing them :-( On Tue, Oct 1, 2013 at 9:12 AM, Huon Wilson wrote: > On 01/10/13 16:13, Oren Ben-Kiki wrote: > >> >> This problem is unique to the String trait. All the other traits (Bool, >&

Re: [rust-dev] The new format!

the future, right? On Tue, Oct 1, 2013 at 9:24 AM, Oren Ben-Kiki wrote: > Ah, so simple. I missed it because it is not listed in the "formatting > traits" list in the documentation. > > This would solve half my problem - I'd no longer need to use {:x} but use >

Re: [rust-dev] The new format!

Yes, both suggestions sound very reasonable. It would also eliminate the need for the Str trait altogether (since the Default fmt function would avoid the allocation). So there would really be no need for most format specifiers, except stuff like controlling the base of integers, etc. On Tue, Oct

Re: [rust-dev] what is stable, what is likely to change, in Rust

Is there any published roadmap for the "reasonable time frame"? The last quotes I saw when searching were ancient and optimistically hoped that Rust will hit 1.0 by the end of this year :-). Is there a goal of reaching 1.0 at some rough time frame or is Rust going for "it will be done when it is do

Re: [rust-dev] Proposal for macro invocation sugar

In general I'd favor anything that would help with https://github.com/mozilla/rust/issues/9358 - that is, allow more eDSL-ish macros. Writing `foo!!(...) { ... }` has the cost of the extra `!` but that really isn't too bad. That said, I wonder why do macro invocations require the outer set of pare

Re: [rust-dev] Proposal for macro invocation sugar

paired brackets in them. > > > On 10/17/2013 06:30 AM, Oren Ben-Kiki wrote: > > In general I'd favor anything that would help with > https://github.com/mozilla/rust/issues/9358 - that is, allow more > eDSL-ish macros. Writing `foo!!(...) { ... }` has the cost of the extra `!

[rust-dev] Strange behavior about Writer trait

I run into the following problem (the code below is a toy example). ``` use std::io::Writer; // Makes no difference if added/removed. trait PrintWithSpice { fn print(&self, writer: &Writer, spice: bool); } struct Bar { bar: ~PrintWithSpice, } impl Bar { pub fn print(&self, writer: &

Re: [rust-dev] Strange behavior about Writer trait

trait `WriterUtil`, but isn't smart enough to figure out a `&Writer` has the trait... On Sat, Oct 19, 2013 at 9:08 AM, Oren Ben-Kiki wrote: > I run into the following problem (the code below is a toy example). > > ``` > use std::io::Writer; // Makes no difference i

Re: [rust-dev] Strange behavior about Writer trait

Fackler > > > On Fri, Oct 18, 2013 at 11:27 PM, Oren Ben-Kiki wrote: > >> Ugh, I was too optimistic. Yes, I can write my code using `MyWriter`, but >> I can't cast any @Writer (such as `io::stdout()`) to it. I guess I should >> just use `@Writer` everywhere for n

Re: [rust-dev] Unified function/method call syntax and further simplification

Interesting idea; in that case, one could string together any series of functions - basically, `.` would become the equivalent of `|>` (or whatever other name you want to call it). That is, instead of writing `baz(bar(foo(x), y), z)` one could write `foo(x).bar(y).baz(z)`. This would make it easier

Re: [rust-dev] Strange behavior about Writer trait

I'm not sure I follow. Assuming that the trait `T` has no method that uses `Self`, then any `impl` requiring `T` should happily accept an `&T` / `@T`. Why penalize non-self-referential traits (like `Writer`), just because some traits (like `AdderIncr`) are self-referential? On Sun, Oct 20, 2013 a

Re: [rust-dev] Unified function/method call syntax and further simplification

Coming from a functional programming perspective, it would still be very nice indeed to easily pipeline a series of functions (not methods). The current method of requiring defining a new trait (with possibly just one impl!) just to be able to use the `.` syntax means discouraging functional style

[rust-dev] What does `once fn` mean?

rtion that the action is only invoked once. Costs in // both extra ugly source code lines and in run-time overhead. string_cell.take() } } ``` So, this works, but boy is it ugly, not to mention inefficient Can someone suggest a better way to achieve this, and shed some light on the stat

Re: [rust-dev] Trait method self parameter type clashes with lifetime annotation required by the implementation

n Fri, Oct 25, 2013 at 7:05 PM, Niko Matsakis wrote: > On Mon, Sep 30, 2013 at 08:10:45PM +0300, Oren Ben-Kiki wrote: > > That's good! But there remains the fact that there's no way to say "my > > lifetime is the same as the struct that contains me". If 'sel

Re: [rust-dev] return type of closure

Off the top of my head, I'd take out the "&" in front of the "|x|" everywhere, it seems like you are borrowing a pointer out of something that is already a borrowed pointer to a function (expected &, found &&, you have one & too many, right? :-). On Sun, Oct 27, 2013 at 2:15 PM, Ramakrishnan Muth

Re: [rust-dev] return type of closure

You got me there... On Sun, Oct 27, 2013 at 6:04 PM, Ramakrishnan Muthukrishnan < vu3...@gmail.com> wrote: > On Sun, Oct 27, 2013 at 6:12 PM, Oren Ben-Kiki wrote: > > Off the top of my head, I'd take out the "&" in front of the "|x|" > > eve

Re: [rust-dev] recursive types

I assume the compiler suggests you replace @Expr with Rc (Rc is defined in std::rc). This means you wouldn't be able to create cycles (that is, expressions must form a tree, or at most a DAG), and that there would be the overhead of reference counting when you create new expressions, clone the poin

Re: [rust-dev] recursive types

If you use ~Expr instead of @Expr, then the expressions would have to form a tree (A = B + C). If you use Rc, you could build a DAG (A = B + B). With @Expr (if that worked), in principle you could allow for cycles (A = B + A), which is probably not what you want. On Mon, Oct 28, 2013 at 8:25 PM,

Re: [rust-dev] recursive types

t 28, 2013 at 2:27 PM, Oren Ben-Kiki wrote: > >> If you use ~Expr instead of @Expr, then the expressions would have to >> form a tree (A = B + C). If you use Rc, you could build a DAG (A = B >> + B). With @Expr (if that worked), in principle you could allow for cycles >>

Re: [rust-dev] This Week in Rust

Indeed. It is invaluable in helping me decide when to pull a new master and be prepared for what I need to fix in my code. Many thanks for doing this! On Tue, Oct 29, 2013 at 10:51 AM, Gaetan wrote: > +1 I just subscribed yesterday and I really appreciates this overview :) > > - > Gaetan >

Re: [rust-dev] RFC about std::option and std::result API

I would love it if '?' was allowed at the end of any identifier, to make it natural to name boolean variables, methods, constants, etc. Having to say is_xxx is ugly IMO. A lint option ensuring this is only applied to boolean typed constructs could help reduce abuse, if this is seen as an issue. On

[rust-dev] Separating heaps from tasks

I am toying with a non-trivial Rust project to get a feel for the language. There's a pattern I keep seeing in my code which isn't easy to express in Rust. I wonder what the "right thing to do" is here. The pattern is as follows. I have some container, which contains some components of different t

Re: [rust-dev] Separating heaps from tasks

On Mon, Nov 4, 2013 at 8:13 AM, Patrick Walton wrote: > On 11/3/13 10:11 PM, Oren Ben-Kiki wrote: > >> At any rate - is this something that makes sense in the Rust view? >> If so, is there a chance of something like that being added (a >> completely separate question :

Re: [rust-dev] Separating heaps from tasks

there's the issue of keeping multiple pools (one per type)... So it gets complex fast, though perhaps a "sufficiently smart library" could still do a good job? On Mon, Nov 4, 2013 at 8:18 AM, Daniel Micay wrote: > On Mon, Nov 4, 2013 at 1:11 AM, Oren Ben-Kiki wrote: > >

Re: [rust-dev] Separating heaps from tasks

in the 1st place. On Mon, Nov 4, 2013 at 8:20 AM, Patrick Walton wrote: > On 11/3/13 10:19 PM, Oren Ben-Kiki wrote: > >> Because they don't allow cycles. >> > > Aha. I personally think we should relax this restriction; it's pretty > onerous. > > Patrick >

Re: [rust-dev] Separating heaps from tasks

inter instead :-( Language support for heaps-separate-from-tasks would have solved it (and a bit more)... On Mon, Nov 4, 2013 at 8:32 AM, Daniel Micay wrote: > On Mon, Nov 4, 2013 at 1:29 AM, Oren Ben-Kiki wrote: > >> Even if RC allowed cycles (I don't quite see how...) the

Re: [rust-dev] Separating heaps from tasks

Essentially, yes. On Mon, Nov 4, 2013 at 11:59 AM, Huon Wilson wrote: > On 04/11/13 20:09, Oren Ben-Kiki wrote: > >> ARCs have their place, sure! But "letting it leak" isn't acceptable in my >> case. >> >> Instead, in my use case, "no delet

Re: [rust-dev] Abandoning segmented stacks in Rust

Note that as memory becomes cheaper and larger there will be more pressure on 64-bit OS-es to switch to large pages; the number of pages needed to map several GBs of memory today is already getting out of hand, causing TLB misses to become a performance issue in some cases - imagine a system with 0

Re: [rust-dev] struct def

I would think: let mut ps = *Points* {xs:~[1], ys:~[1]}; let mut ps : *Points* = *Points* {xs:~[1], ys:~[1]}; In Haskell-speak, there is a different between the "type" and the "constructor", even though by convention they are given the same name. On Wed, Nov 6, 2013 at 9:46 AM, spir wrote: >

[rust-dev] The let keyword

Coming from Haskell, I realize some of the background of using this syntax form. But looking at my code, I sometimes wish I could just write `x: Foo := foo();` instead of `let x: Foo = foo();`. All these `let`s in the code seem noisy. I suppose this was an explicit design decision - I wonder if any

Re: [rust-dev] The let keyword

I didn't consider that; `pattern := expression` would require "infinite lookahead" in the parser, I guess. Good point. Thanks! On Wed, Nov 6, 2013 at 8:56 PM, Patrick Walton wrote: > `let` tells the parser that there's a pattern coming up. > > Languages that do 'x := whatever' can never have de

Re: [rust-dev] Abandoning segmented stacks in Rust

Does ditching segmented stacks mean we can start getting a stack trace when a task `fail!`s? Or is this an unrelated issue? The lack of stack traces is extremely tedious when debugging failed assertions... ___ Rust-dev mailing list Rust-dev@mozilla.org h

Re: [rust-dev] Abandoning segmented stacks in Rust

Corey Richardson wrote: > Entirely unrelated. Do note that we have stack traces *now*, as long > as you're using gdb to get them :). Break on `rust_begin_unwind` or > "catch throw". > > On Fri, Nov 8, 2013 at 1:27 AM, Oren Ben-Kiki wrote: > > Does ditching segmented

Re: [rust-dev] Abandoning segmented stacks in Rust

8, 2013 at 1:45 AM, Oren Ben-Kiki wrote: > >> Good to know! The GDB stack traces leave something to be desired, though >> - e.g. the way it reports closures isn't really very useful (adding source >> file name and line number would be really good there). But it is certainly

Re: [rust-dev] Abandoning segmented stacks in Rust

Added https://github.com/mozilla/rust/issues/10350 then :-) On Fri, Nov 8, 2013 at 9:00 AM, Daniel Micay wrote: > On Fri, Nov 8, 2013 at 1:59 AM, Daniel Micay wrote: > >> On Fri, Nov 8, 2013 at 1:52 AM, Oren Ben-Kiki wrote: >> >>> How bad would it be to add anothe

Re: [rust-dev] About owned pointer

Now I'm confused; doesn't this mean str is fixed size, so the proposal to just use "str" for the 3-word struct and have ~str and &str just be the normal thing makes sense after all? On Fri, Nov 8, 2013 at 8:56 PM, Marvin Löbel wrote: > On 11/08/2013 07:50 PM, Igor Bukanov wrote: > >> On 8 Novembe

Re: [rust-dev] About owned pointer

"str") to be close to the "physics", so people would be able to easily reason about the code behavior. This would also lend support to the proposal of seeing str as a struct and not as a pointer. On Fri, Nov 8, 2013 at 11:22 PM, Patrick Walton wrote: > On 11/8/13 11:33 AM, Oren B

Re: [rust-dev] About owned pointer

Sat, Nov 9, 2013 at 12:04 AM, Patrick Walton wrote: > On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: > >> So, the core question is whether we think of str as an object or as a >> pointer. Either we see it as an object (with fixed size, 3 words), which >> internally holds

Re: [rust-dev] About owned pointer

Yes, the down side is another level of indirection. This could be optimized away for &'static str, but not for &str. Good point. On Sat, Nov 9, 2013 at 12:06 AM, Patrick Walton wrote: > On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: > >> Also, str != ~[u8] (for good reaso

Re: [rust-dev] About owned pointer

ssing in this thread, that is. On Sat, Nov 9, 2013 at 12:09 AM, Patrick Walton wrote: > On 11/8/13 2:08 PM, Oren Ben-Kiki wrote: > >> >> I don't follow. ~Trait is a pointer, and therefore its size is fixed. >> There are checks in place to prevent using a trait as a type (

Re: [rust-dev] About owned pointer

No need to apologize. You are quite right, this is tricky and there's a good reason for the current design choices (perhaps there are better, but they are far from obvious). I wish I could put more time into deep thinking about this... which, of course, you can :-) On Sat, Nov 9, 2013 at 12:32 AM

Re: [rust-dev] Help: How to execute the owned method "produce_obj"?

It wouldn't be self.something because it doesn't take a self argument. Try Pool::produce_obj::(...) ? Or add a self argument to it and then call it normally. On Sat, Nov 9, 2013 at 1:31 AM, wuyunlong wrote: > struct Pool{ > produce_obj : ~fn()->T, > elements : ~[T] > } > > impl

[rust-dev] State of private

I find that in several cases I would like to have sibling modules access private members, that is, allow "foo::bar::Bar" access the private members of "foo::baz::Baz", but disallow any code in "qux::*" from accessing these members. Currently in these cases I am forced to expose as public stuff tha

Re: [rust-dev] State of private

Many thanks for the replies. My problem is actually in accessing private methods/members of a struct defined in a different, but "very closely related" module. It seems @ nikomatsakis is saying in the final text comment of https://github.com/mozilla/rust/issues/82

Re: [rust-dev] State of private

that. Thanks, Oren Ben-Kiki On Fri, Nov 8, 2013 at 10:44 PM, Patrick Walton wrote: > On 11/8/13 10:43 PM, Oren Ben-Kiki wrote: > >> Looking at the same thread, I see nobody asked about a possibility of >> keeping the existing rules, but also adding a "friend&quo

Re: [rust-dev] State of private

rrent Rust direction. A friend keyword, on the other hand, should be pretty simple to implement and is a rather minor tweak to the existing system. On Sat, Nov 9, 2013 at 5:50 AM, Gábor Lehel wrote: > > On Sat, Nov 9, 2013 at 7:43 AM, Oren Ben-Kiki wrote: > >> Many thanks for the

Re: [rust-dev] formats 'Standard' {} and 'Poly' {:?}

I thought the trait for `{}` was called `Default`. At any rate, I also don't understand why we need both `{}` and `{:s}`, `{:i}`, etc. There's some reason for `{:x}` (change the output base to hexadecimal), but that's about it. ___ Rust-dev mailing list R

[rust-dev] "Implementation Inheritance" / mixins

invoke overriden methods - but that may be tricky to implement). At any rate, I'm not claiming this is necessarily the best approach for Rust; I'm just wondering, what is the proposed way to address this use case? None of the manual approaches seems very appealing (unless there's a

Re: [rust-dev] "Implementation Inheritance" / mixins

> On 11/12/13 5:16 AM, Oren Ben-Kiki wrote: > >> I googled around and this has been asked before several times; there are >> answers that use obsolete syntax and Rust concepts, so I thought it >> might be a good idea to revisit the issue. >> >> The basic use cas

Re: [rust-dev] "Implementation Inheritance" / mixins

On Tue, Nov 12, 2013 at 9:43 AM, Patrick Walton wrote: > On 11/12/13 4:32 PM, Oren Ben-Kiki wrote: > >> Ah, thanks. I wasn't aware of that. I should start tracking that RSS >> feed... >> >> I am very concerned that single-inheritance takes the language in the

Re: [rust-dev] "Implementation Inheritance" / mixins

ld offer a somewhat different tradeoff than the source code transformation approach, so you might like them better :-) On Tue, Nov 12, 2013 at 9:56 AM, Patrick Walton wrote: > On 11/12/13 4:53 PM, Oren Ben-Kiki wrote: > >> "Your solution does not match the performance of single

Re: [rust-dev] "Implementation Inheritance" / mixins

ue, Nov 12, 2013 at 12:46 PM, spir wrote: > On 11/11/2013 09:16 PM, Oren Ben-Kiki wrote: > >> At any rate, I'm not claiming this is necessarily the best approach for >> Rust; I'm just wondering, what is the proposed way to address this use >> case? None of the ma

Re: [rust-dev] linking to cells inside a data structure

I have been struggling with variants of this for a while and there's no "best" solution. First, if the array holds values (as opposed to pointers to values), then pretty much your only option is to replace your pointers with indices to the array. You'd need access to the container to access the va

Re: [rust-dev] linking to cells inside a data structure

Yes, you lose the ability to deallocate individual nodes. Pretty hard to express in a type system. Still I wish I could at least have the compiler help me to ensure my unsafe pointers never escape the lifetime of the container; right now I must trust the programmer (and in my case, the container ba

Re: [rust-dev] copying pointers

For linked lists with no cycles, why not use Option> (or RcMut)? On Tue, Nov 12, 2013 at 4:06 PM, spir wrote: > PS: What would be, in fact, the rusty way for a simplissim linked list. I > use Option<~Cell> for now, to have something clean (None) to end the list, > since Rust looks rather functi

Re: [rust-dev] "Implementation Inheritance" / mixins

It seems the argument on single-inheritance hinges on the following use case: struct Foo { foo: int } struct Bar : Foo { bar: bar } fn main() { let myFoos = [Foo{ foo: 1 } as ~Foo, Bar{ foo: Foo{foo: 1}, bar: 2} as ~Foo]; for myFoo in myFoos.iter() { myFoo.foo; // Fixed offset ac

Re: [rust-dev] "Implementation Inheritance" / mixins

This is probably as good as we can get in the current system (I do something similar in my code today). I also think you probably need both "super" and "mut_super", so it would be two methods to implement instead of one (still pretty good). I wonder whether it is possible to write a macro that aut

Re: [rust-dev] "Implementation Inheritance" / mixins

Reed wrote: > I'm not clear on why LLVM wouldn't be able to inline super() calls. It's > static dispatch, so it knows exactly what function is being called. > > > On Wed, Nov 13, 2013 at 1:25 AM, Oren Ben-Kiki wrote: > >> This is probably as good as we can get

Re: [rust-dev] linking to cells inside a data structure

You are right that the compiler needs to ensure no pointers escape the struct itself, so it is OK to move it (and all the pointers it includes). Intuitively this would require another level of static type checking (whether there are existing outside-the-struct borrowed pointers at any point), proba

Re: [rust-dev] "Implementation Inheritance" / mixins

Hmmm. Perhaps I was too hasty. It would be interesting to look at the generated binary code and see if it actually work this way... On Wed, Nov 13, 2013 at 8:08 PM, Eric Reed wrote: > I'm not sure I follow. > My implementation doesn't use any trait pointers, so the only time there > were would b

Re: [rust-dev] The future of M:N threading

On Wed, Nov 13, 2013 at 10:51 PM, james wrote: > On 13/11/2013 19:30, Daniel Micay wrote: > I had high hopes of Rust having lightweight segmented stacks and precise > per-task > GC and portability too. Sort of Erlang with type safety and AOT > compilation with a > sane model. > That's somethin

  1   2   >