Re: [rust-dev] Function definition syntax

+1 On Mon, Jul 29, 2013 at 10:40:37PM -0700, Lindsey Kuper wrote: > On Mon, Jul 29, 2013 at 4:29 PM, Wojciech Miłkowski > wrote: > > That said I wonder why the function definition has form: > > fn name(var: type, ...) -> return_type {...} > > instead of more unified: > > fn name(var: type, ...):

Re: [rust-dev] Function definition syntax

On Wed, Jul 31, 2013 at 08:59:07AM +1000, Brendan Zabarauskas wrote: > On 31/07/2013, at 7:29 AM, Graydon Hoare wrote: > > > we used to use [T,U,V] like Scala, but user feedback decisively rejected > > it. My kingdom > > for a few extra bracket characters! > > > > Maybe I should be more dictato

Re: [rust-dev] Getting fully qualified name from a path

The answer depends on what you want. You can use `ty::item_path()` which will give you something like what you want, but maybe not quite. Basically if `ty::item_path()` refers to an item `Y::Z` in crate `X`, it will give a path like `X::Y::Z`. But this path may not be valid relative to the current

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

One simple way to iterate over a vector and preserve the right to push onto it is to use something like a while loop instead: let mut i = 0; while i < vec.len() { process(vec[i]); // may alter vec } It would be trivial to package this pattern up into a special iterator that o

Re: [rust-dev] Borrowed pointers with lifetime in structures cause weird errors

Hi, Sorry for not responding more quickly. I've been wanting to sit down and work out your example; I am confident that it can be made to work, although from reading it quickly it sounds like a case that might be better served with two lifetime parameters, which are not yet supported (on my list..

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

There may be another way, but one safe option is to use util::replace to always set the `root` field to None but preserve the old value, as shown below (this code compiles). In general, the rule you are running into (which prevents mutation to the path that contains a borrowed &mut) is one that I

Re: [rust-dev] Issue in borrowing

Depending on what you are trying to do, there are multiple answers to your (implied) question. In general you are not permitted to have two borrows of the same element at the same time; in this case, your program is being rejected because the compiler is conservative and it assumes that any two arr

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

On Wed, Aug 21, 2013 at 10:47:20PM -0400, Corey Richardson wrote: > - Metadata is scary. It's a hairy part of the codebase that I sure > don't understand. I know its purpose, more or less, but not the > specifics of how or why things are encoded. Michael Sullivan could > speak more to this, he is t

Re: [rust-dev] Using extern functions from another crate

On Thu, Aug 22, 2013 at 03:31:05PM -0700, Vadim wrote: > Oh, ok, so this will be fixed? Any idea when? :-) Interesting problem. I guess I don't know enough about how our linking model works to know how to fix this. I thought we'd get the extern fns when we linked in the source crate. In any ca

Re: [rust-dev] Dynamic in Rust

Currently, this is not directly supported, though downcasting in general is something we have contemplated as a feature. It might be possible to create some kind of horrible hack based on objects. A trait like: trait Dynamic { } impl Dynamic for T { } would allow any value to be cast to

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

I find I have surprisingly strong opinions about this. In particular, I don't care for any of the options. Rather I prefer option D, which looks like: fn foo() { /*! * Summary * * Body text */ } My reasoning: - I want the comment INSIDE the fun

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

12:53:07PM -0700, Brian Anderson wrote: > On 08/26/2013 07:07 AM, Niko Matsakis wrote: > >I find I have surprisingly strong opinions about this. In particular, > >I don't care for any of the options. Rather I prefer option D, which > >looks like: > > > > f

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

https://github.com/mozilla/rust/issues/8787 On Mon, Aug 26, 2013 at 12:53:07PM -0700, Brian Anderson wrote: > On 08/26/2013 07:07 AM, Niko Matsakis wrote: > >I find I have surprisingly strong opinions about this. In particular, > >I don't care for any of the options. Rath

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

On Fri, Aug 30, 2013 at 05:50:40PM -0700, Patrick Walton wrote: > Brian pointed out a massive soundness hole in this, unfortunately. > The problem is that you can read from the original locations; the > right to read is not "shut off" during the borrow. I think the fix > would have to be to replace

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

haven't really about that before) Niko On Mon, Sep 02, 2013 at 08:04:17PM -0400, Niko Matsakis wrote: > On Fri, Aug 30, 2013 at 05:50:40PM -0700, Patrick Walton wrote: > > Brian pointed out a massive soundness hole in this, unfortunately. > > The problem is that you can re

Re: [rust-dev] Questions about linked lists in Rust

On Mon, Sep 02, 2013 at 04:37:34PM -0700, Tim Chevalier wrote: > There are two list modules because one is a singly linked list -- > list.rs -- and one is a doubly linked list -- dlist.rs . Off the top > of my head I'm not sure if there's a reason why list.rs uses @ > pointers. The reason that lis

Re: [rust-dev] Out of -Z flags

Just switch it to u64. Niko On Tue, Sep 03, 2013 at 02:34:22PM -0400, Corey Richardson wrote: > Right now Z flags are implemented using a bit flag stored in a uint, > which is only reliably 32 bits on the platforms we use. We could > extend it to a u64, or we could use an enum, but we can't cont

Re: [rust-dev] instantiating parameterized impls

Hi David, My current thinking on the matter is that eventually, I would like to take advantage of the coherence rules to permit a program like this. Coherence means that given a specific type T and trait U, we can always tell whether T implements U. This implies that we could do the check as you

Re: [rust-dev] Subtyping in Rust

By subtyping, do you mean defining class hierarchies as in C++ or Java? This is currently not supported. Typically such hierarchies are modeled either using an `enum` (most common) or using a `trait`. Enums are perfect for cases where there is a limited set of possibilities. Traits are perfect fo

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

Hi Alex, This is Issue #5121, I believe. That error message is certainly confusing but basically it's a bug and known limitation. I hope to lift it...soonish as part of the fix for finishing the work on lifetime syntax (#4846). Niko On Fri, Sep 06, 2013 at 08:27:49PM +0100, Alex wrote: > Hey E

Re: [rust-dev] Subtyping in Rust

y, I remember that the various pointer types can be implicitly > converted. I couldn't find anywhere where these conversions are defined. Is > my memory bad or my search skills? > > Thanks, Nick > > > On Tue, Sep 10, 2013 at 1:34 AM, Niko Matsakis wrote: > > &

Re: [rust-dev] Rust compiler bootstrapped

People seem to reimplement C++ compilers, despite there being an enormous amount of complex just parsing it... that said, the trickiest and least specified part of the type checker right now is probably the type inferencing algorithm, which I hope we can overhaul for something that is clearer or mo

rust-dev@mozilla.org

On Thu, Sep 19, 2013 at 03:15:47PM +, Bill Myers wrote: > BTW, how about keeping it, and calling it "&volatile" instead of > "&const", since that's what C uses to name something that can be > changed outside the program's control? That's the best proposed name I've seen. One problem might be t

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

We have considered the option of struct inheritance, and in that design we included the option of a trait being limited to types that extend a struct. This creates a less general trait, similar to what happens in Java is you specify an abstract interface in terms of a class rather than an interface

Re: [rust-dev] How to express "T : Foo implies T : Foo" ?

I believe this is due to invalid assumptions in the compiler's trait implementation (related to issue #7590). In particular some code assumes that a trait will only be implemented for a single set of type parameters, and it may be that this code is causing incorrect type unifications. In general th

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

On Wed, Sep 25, 2013 at 08:29:17AM -0700, Patrick Walton wrote: > If we did this, we wouldn't know whether to parse a pattern or an > expression when starting a statement. This isn't fixable without > trying to define some sort of cover grammar that covers both > expressions and patterns, like ECMA

Re: [rust-dev] Crate-scoped non-trait implementations

It is not clear to me how to apply lexical-based privacy rules to method calls, though I am not opposed. How can we determine if the module where the method is declared is exported? I guess that the idea is simply to climb the module hierarchy, checking that each module between the declaration of t

Re: [rust-dev] Connecting at the Mozilla Summit

On Mon, Sep 30, 2013 at 05:21:14PM -0700, Brian Anderson wrote: > I'm in Brussels. Me too. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] "Go 1.1 Function Calls"

Thanks for the link. I don't think it's too relevant: this is basically an implementation detail for how one chooses to attach the data to a closure pointer. We've opted to make closure "pointers" two words, one for the environment and one for the code pointer. Go seems to be moving to a one word r

Re: [rust-dev] Mutability Overloads

On Wed, Oct 09, 2013 at 10:37:13AM -0700, Patrick Walton wrote: > Perhaps the right thing would be something like mutability > variables: `fn reflector(&M self) -> &M Reflector`. Of > course then integrating a pointer of unknown mutability introduces > borrow check issues similar to those we have w

Re: [rust-dev] return type of closure

Incidentally, my preferred way to "return a closure" is to use an impl like so: struct ntimes(times: uint, value: T) -> T; impl ntimes { fn call(&mut self) -> Option { if self.times == 0 { None } else { self.times -= 1;

Re: [rust-dev] recursive types

You may just want to enable the garbage-collection feature gate by adding `#[feature(managed_boxes)];` to the top of the file. We have currently made `@T` types "opt-in" because we expect the syntax to change (as the message notes) and we expect the collector to change from a ref-counting to a trac

Re: [rust-dev] More on stack safety

If I understand correctly, what you are proposing is to offer fixed size stacks and to use a guard page to check for stack overflow (vs a stack preamble)? My two thoughts are: 1. I do think segmented stacks offer several tangible benefits: - Recursion limited only by available memory / address s

Re: [rust-dev] More on stack safety

On Tue, Oct 29, 2013 at 04:21:35PM +0100, Igor Bukanov wrote: > This is a weak argument. If one needs that much memory, then using an > explicit stack is a must as it allows for significantly more compact > memory presentation. I considered this when I wrote the e-mail. I partially agree but not f

Re: [rust-dev] return type of closure

On Tue, Oct 29, 2013 at 10:14:13PM +1100, Brendan Zabarauskas wrote: > > struct ntimes(times: uint, value: T) -> T; > > > Does this syntax work at the moment? My mistake, I meant to leave off the `-> T`. It would just be: struct ntimes(times: uint, value: T) -> T; impl ntimes {

Re: [rust-dev] More on stack safety

On Tue, Oct 29, 2013 at 04:24:49PM -0400, Daniel Micay wrote: > If we want to unwind on task failure, we'll need to disable the `prune-eh` > pass that bubbles up `nounwind` since every function will be able to > unwind. I think it will cause a very significant increase in code size. That's too bad

Re: [rust-dev] Stack management in SpiderMonkey or aborting on stack overflow could be OK.

I certainly like the idea of exposing a "low stack" check to the user so that they can do better recovery. I also like the idea of `call_with_new_stack`. I am not sure if this means that the default recovery should be *abort* vs *task failure* (which is already fairly drastic). But I guess it is a

Re: [rust-dev] Mysterious comment

On Wed, Oct 30, 2013 at 05:02:24PM +, Sanghyeon Seo wrote: > src/librustc/middle/trans/callee.rs line 614 says: > > In particular, for lang items, it is invoked with a dest of > None, and > > Did we lose the comment or was it always an incomplete comment? > And what (in particular) is about l

Re: [rust-dev] More on stack safety

Currently, Rust does not pre-empty. I still hope we can leverage the O/S for pre-emption rather than having to implement it ourselves. Niko On Thu, Oct 31, 2013 at 10:07:51PM +0800, Ben Kloosterman wrote: > > > > The big issue here then is really that rust tasks can be pre-empted, and > > theref

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

I am generally in favor of this proposal. It seems to be a reasonable way forward. It is unclear to me how many types would benefit from this approach of having methods for each variant, but `Result` certainly does. With respect to possible confusion between `is_ok()` and `ok()` -- I think that th

Re: [rust-dev] Separating heaps from tasks

This is not a complete answer to your question, but I have toyed with the idea of an (unsafely implemented but with safe interface) message allocation library that would partially address your use case. Unfortunately I think that implementing it would require higher-kinded types. The basic would b

Re: [rust-dev] the inter-play of struct type impl, traits, & type params

On Tue, Nov 05, 2013 at 08:53:45PM -0800, Ziad Hatahet wrote: > This relieves one form writing wrapper classes in order for certain > structs to adhere to particular interfaces. Partially, yes. Where this breaks down is if you have a type from one crate and an interface from another. We can't help

Re: [rust-dev] About owned pointer

On Thu, Nov 07, 2013 at 04:48:06PM -0500, Daniel Micay wrote: > Owned boxes shouldn't be commonly used. There's close to no reason to use > one for anything but a recursive data structure or in rare cases for an > owned trait object. I don't really agree with this statement. I agree that those are

Re: [rust-dev] About owned pointer

On Fri, Nov 08, 2013 at 07:32:02AM +0800, Liigo Zhuang wrote: > It's so confusing. If it's not owned box, why not remove ~? Make "str" > default be dynamic should OK. I am not sure why Daniel says that a `~str` or `~[]` is not an "owned box". I guess he's using the term in some specific way. I con

Re: [rust-dev] About owned pointer

On Thu, Nov 07, 2013 at 08:40:27PM -0500, Jason Fager wrote: > Let me ask another way: what's wrong with thinking of ~ just as meaning > "allocate to the heap and subject to move semantics"? When would that > simplification bite me in the ass regarding owned boxes vs strs/vecs? I don't consider

Re: [rust-dev] About owned pointer

On Fri, Nov 08, 2013 at 07:39:59AM -0500, Daniel Micay wrote: > By owned box I just mean a type you can pass to `fn foo(x: ~T) { }` > rather than something that's owned and has a heap allocation. Once the DST work is done, you will be able to pass a ~[T] to a function like `fn foo(x: ~T) { }`. N

Re: [rust-dev] About owned pointer

On Fri, Nov 08, 2013 at 06:46:37AM -0500, Daniel Micay wrote: > I don't think the need to do micro-optimizations like this is *common* > though. I honestly don't know how common or uncommon various scenarios are. All I was doing in my e-mail was highlighting scenarios where indirection is a good i

Re: [rust-dev] About owned pointer

On Sat, Nov 09, 2013 at 09:46:38AM +1100, Huon Wilson wrote: > Ah, of course. Presumably this means that `Rc` or `Rc` > would require a separate code-path? I've been thinking about this somewhat. I'm not sure if this is true. And in fact while both `Trait` and `str` are "dynamically sized types",

Re: [rust-dev] About owned pointer

On Sat, Nov 09, 2013 at 09:43:45AM +1100, Huon Wilson wrote: > This will make transmuting ~ to get a * (e.g., to allocate memory for > storage in an Rc, with automatic clean-up by transmuting back to ~ on > destruction) harder to get right, won't it? See my other e-mail about choosing a representa

Re: [rust-dev] returning an item from a collection

On Mon, Nov 11, 2013 at 03:48:37PM +0100, spir wrote: > Also, what does > let y = x; > mean in Rust if x's type is constant (as opposed to a generic type > var)? Does it depend on the exact type? and specifically what happens > in the case of simple, atomic, type? The meaning is: - shallow

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

> I don't know how to make that sound, unfortunately, other than using > an arena and allocating all the nodes into it (losing the ability to > deallocate individual nodes). Arenas don't require that you lose the ability to deallocate individual nodes. See my thoughts in #10444. Briefly, the idea

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

On Tue, Nov 12, 2013 at 02:51:53PM +0200, Oren Ben-Kiki wrote: > 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 values, of > course. Bu

Re: [rust-dev] Danger of throwing exceptions through Rust code

The interplay between exceptions and foreign code is a complicated topic. Here are some miscellaneous thoughts. 1. I don't believe there is any memory safety reason we could not support catchable exceptions in Rust. The main concern is more one of good design; it's difficult to recover meani

Re: [rust-dev] Built-in types should accept a pointer rhs-argument to binary operators

This is to some extent in flux (see bug #10337). But the branch I am working on actually reports *both* usages as errors. The correct code would be: *p + n n + *p Basically, a binary operator like `l + r` is translated to something similar to the following (which assumes universal function

Re: [rust-dev] About owned pointer

On Fri, Nov 08, 2013 at 04:47:24PM +0100, Diggory Hardy wrote: > What's wrong with sticking with convention here? E.g. C++'s `string` and > `vector` are objects containing two or three pointers. D's arrays and > `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought > of t

Re: [rust-dev] Rethinking Linking in Rust

A few quick questions and comments: On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote: > I've been thinking about static linking recently, along with a little bit of > linking in general, and I wanted to see what others thought. > > # The Goal > > Primarily, I believe that if desired

Re: [rust-dev] Rethinking Linking in Rust

On Fri, Nov 15, 2013 at 09:28:49AM -0800, Alex Crichton wrote: > To this end, I mainly > point out that rust should roll in local native static libraries, and > just live with global native dynamic libraries. How does rustc know the difference? Because the "local native" libraries are tagged as #[

Re: [rust-dev] Built-in types should accept a pointer rhs-argument to binary operators

On Thu, Nov 14, 2013 at 09:05:40PM +0200, Tommi wrote: > > In other words, no autoderef or other transformation takes place. We > > just look for a matching trait. Instead we just pass the values in by > > reference. The reason for passing by reference is so that you can > > compare linear types m

Re: [rust-dev] Built-in types should accept a pointer rhs-argument to binary operators

On Sat, Nov 16, 2013 at 11:08:01AM +0200, Tommi wrote: > On 2013-11-16, at 1:37, Tommi Tissari wrote: > > > But shouldn't the signature be: > > fn cmp(x: &[T], y: &[T]) -> bool > > Oh, wait I think I know what the answer to that question is going to be. The > comparison trait requires the signa

Re: [rust-dev] Type system thoughts

On Fri, Nov 15, 2013 at 05:05:28PM +0100, Gábor Lehel wrote: > I have some ideas about typey things and I'm going to write them down. It > will be long. I haven't read this all yet, I just want to respond to the first few paragraphs. :) > It would be nice if `Trait1 + Trait2` were itself a trait,

Re: [rust-dev] freeing of locals

I am planning to submit a PR changing this so that we have no need of zeroing memory out. This does mean that some programs which today are legal will become illegal, because the compiler must know unambiguously at each point what is to be freed: in other words, if one path of an if/else consumes a

Re: [rust-dev] Removing some autoref magic

On Wed, Nov 20, 2013 at 12:30:59AM -0800, Vadim wrote: > I found this > postby > Niko, and it seems that at the time everyone agreed that implicit > moving > actually makes things more clear. Why is this different now,

Re: [rust-dev] Removing some autoref magic

One caveat: this e-mail made it sound as if the proposal were universally favored at the meeting, but I at least feel conflicted, though I may not have that clear. I started writing a response but it got long, so I moved it to a blog post: http://smallcultfollowing.com/babysteps/blog/2013/11/20/pa

Re: [rust-dev] list of all reserved keywords of the language

On Tue, Nov 19, 2013 at 07:19:15AM -0800, Patrick Walton wrote: > The liveness analysis uses the infinite nature of `loop`, and it was > felt that special-casing the `true` boolean like Java does is a hack. I personally like `loop`. It reads nicely. It happens quite frequently that I have a loop t

Re: [rust-dev] Removing some autoref magic

On Wed, Nov 20, 2013 at 11:23:57AM -0700, David Piepgrass wrote: > I'm wondering something. Have the Rust developers considered the > possibility of using references instead of pointers? It seems to me > that this would eliminate a lot of the need for "autoderef". Now I'm > not well-equipped to tal

Re: [rust-dev] list of all reserved keywords of the language

On Wed, Nov 20, 2013 at 09:33:15PM +0100, Gábor Lehel wrote: > This is an even sillier idea, but then what about keeping `loop` and > dropping `while`? We considered this for a while -- as well as making `loop if` be the way you write `while` -- and decided "why antagonize people." Besides, `while

Re: [rust-dev] Type system thoughts

On Fri, Nov 15, 2013 at 05:05:28PM +0100, Gábor Lehel wrote: > The next few are going to be about higher- (or just different-) kinded > generics. To avoid confusion, I'm going to use "built-in trait" to mean > things like `Freeze` and `Send`, and "kind" to mean what it does everywhere > else in the

Re: [rust-dev] RFC: Put Unicode identifiers behind a feature gate

I'm fine with this, but I wonder: will we ever have more opinion or information than we have now? Can we just survey what e.g. ES6 does and copy them? On Thu, Nov 21, 2013 at 08:53:52PM -0800, Patrick Walton wrote: > There are several issues in the backwards-compatible milestone > related to Unic

Re: [rust-dev] Mentoring + E-easy

This is a great idea. Niko On Tue, Nov 26, 2013 at 03:58:58AM -0500, Corey Richardson wrote: > Hey fellow Rusties, > > We have a fair number of new contributors, and my devious mind wonders > how we can get more. My first thought was a new tag, E-mentored, where > someone can volunteer to ment

Re: [rust-dev] Persistent data structures

On Wed, Dec 04, 2013 at 12:23:35AM -0800, Patrick Walton wrote: > Not without higher kinded types (which eventually we do want--so the > answer is "not yet"). This. That said, I imagine that if we do it right, it'll be possible to write one persistent map implementation that can be used with GC, A

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

On Fri, Dec 06, 2013 at 07:00:53PM -0500, Palmer Cox wrote: > Why not use Result instead of Option for these types of things? I agree. I've personally been moving towards `Result` in preference to `Option` when one of the branches reflects an error. It's worth noting that the compiler could still

Re: [rust-dev] Safely writing iterators over idiomatic C structures

Please see: http://smallcultfollowing.com/babysteps/blog/2013/10/24/iterators-yielding-mutable-references/ http://smallcultfollowing.com/babysteps/blog/2013/10/24/iterators-yielding-mutable-references-take-2/ Those posts discuss a lot of things, but I believe the also cover the tradeoffs involved

Re: [rust-dev] Define copyable types for [T, ..2] static vector initialization

On Sat, Nov 30, 2013 at 12:53:24AM -0500, Ashish Myles wrote: > I have been waiting on integer parameters on traits since I first ran > into Rust, but the rust team might be avoiding that to prevent getting > Turing complete generics/templates. I assume we'll get to it eventually. Niko _

Re: [rust-dev] RFC: Future-proof for unboxed closures

This is good to think about, though I think writing `&mut || foo` feels like a nonstarter to me. I still feel that `&my` -- meaning, a pointer that gives ownership of the referent but not the memory where the referent lives -- is the right approach here. Basically, the type of `|| ...` would be `&

Re: [rust-dev] RFC: Future-proof for unboxed closures

On Sat, Jan 25, 2014 at 12:31:00AM -0500, Niko Matsakis wrote: > As a bonus, `&my` is perfect for the `drop` trait. Thinking on this more, I don't actually think `&my` is perfect for the drop trait, or at least not any more perfect than normal by-value. I still think it's a

Re: [rust-dev] RFC: Future-proof for unboxed closures

On Sat, Jan 25, 2014 at 07:07:32PM +0100, Gábor Lehel wrote: > If you wanted to pass an unboxed closure without indirection though, like > `fn foo>(x: T)`, then you would have to explicitly dereference > the closure, i.e. `foo(*|u| r)` (which might be OK). Why would you want to do that? There is n

Re: [rust-dev] RFC: Future-proof for unboxed closures

On Mon, Jan 27, 2014 at 08:33:57PM +0100, Gábor Lehel wrote: > I think this question has a more general form, namely: when should I pass > by value and when using &move/&my? I expect this will come up quite a bit > if we add the latter. Yes, I agree. The main reason to use `&move/&my` is to permit

Re: [rust-dev] static mut and owning pointers

Probably this should yield an error -- I tend to think we should only permit moves that we cannot enforce from `*` pointers, just to add an extra barrier. Niko On Tue, Jan 28, 2014 at 12:12:23PM -0800, Kevin Ballard wrote: > Your code is moving the contents of Option<~MyStruct> into the match ar

Re: [rust-dev] Compile-time function evaluation in Rust

On Tue, Jan 28, 2014 at 07:01:44PM -0500, comex wrote: > Actually, Rust already has procedural macros as of recently. I was > wondering whether that could be combined with the proposed new system. I haven't looked in detail at the procedural macro support that was recently added, but off hand I t

Re: [rust-dev] What of semi-automated segmented stacks ?

One option that might make a lot of sense is having an API like this: start_extensible_stack(initial_size, || ...) consider_stack_switch(required, || ...) The idea is that `start_extensible_stack` allocates a stack chunk of size `initial_size` and runs the closure in it. `consider_stack_s

Re: [rust-dev] Syntax for custom type bounds

Regarding the marker types, they are somewhat awkward, and are not the approach I originally favored. But they have some real advantages: - Easily extensible as we add new requirements, unlike syntax. - Easily documented. - These bounds are only used for unsafe code, so it's not something ordina

Re: [rust-dev] Syntax for custom type bounds

On Sat, Feb 01, 2014 at 03:42:45PM -0800, Vadim wrote: > Since &'a Foo currently means "the return value is a reference into > something that has lifetime 'a", 'a Foo feels like a natural extension > for saying "the return value is a reference-like thing whose safety depends > on something that ha

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

On Sun, Feb 02, 2014 at 10:30:51AM +0100, Benjamin Herr wrote: > ... while C# apparently compromises and puts the type parameters between > the function name and value parameter list, but leaves the bounds for > later: > > public static bool Contains(IEnumerable collection, T item) >

Re: [rust-dev] Futures in Rust

Within a single function we are more permissive, I think. I've been debating if we should stop that, just for consistency. There are also some bugs concerning closures. I hope to close those soon with my patch for #6801. On Wed, Jan 29, 2014 at 02:39:01PM -0800, Vadim wrote: > I've tried to simula

Re: [rust-dev] Futures in Rust

On Tue, Feb 04, 2014 at 02:15:39PM -0800, Vadim wrote: > I think that'd be too annoying. I'm not sure, I suspect it would have very little impact. It would probably simplify the code (always a win) and it would also have some very nice properties. In particular, if you took an `&mut` pointer to a

Re: [rust-dev] Syntax for custom type bounds

On Tue, Feb 04, 2014 at 11:41:21PM -0800, Vadim wrote: > How does this apply to traits?If I look at "trait MutableVector<'a, T>" > there's nothing that would connect 'a and self. There is no necessary connection between 'a and the receiver. For example, you might have: impl MutableVector

Re: [rust-dev] Prefix on extern blocks

On Thu, Feb 06, 2014 at 02:19:06PM +0100, Magnus Holm wrote: > Hi, > > Idea: > > #[prefix="http_parser_"] > extern { > pub fn init(parser: *http_parser, _type: enum_http_parser_type); > … > } > > This have a few niceties: > > * You don't have repeat the prefix in every function >

Re: [rust-dev] fork-join parallelism library

Hi Mahmut, More important than the name of the library, I think, is the shape of the API that it offers. There is some prior work in Servo and also I have been tinkering with some designs. I was hoping to write a new blog post with my latest thoughts in the next day or so but you can read up on an

Re: [rust-dev] Breaking change: new Hash framework has landed

This looks very cool. On Mon, Feb 24, 2014 at 11:31:19AM -0500, Erick Tryzelaar wrote: > I'm happy to announce that Rust's new hashing framework has landed in: > > https://github.com/mozilla/rust/pull/11863 > https://github.com/mozilla/rust/pull/12492 > > This PR has has changed how to declare

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

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: Today, if you do a mutable borrow of a local variable, you lose the ability to *write* to that variable except through the new referenc

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

On Tue, Feb 25, 2014 at 03:18:19PM -0800, Kevin Ballard wrote: > If you can construct the new value independently of the old, sure. But if > constructing the new value > requires consuming the old, then you can't. I think lifting restrictions on moves beyond trvivial cases is going to turn out ve

[rust-dev] RFC: Opt-in builtin traits

>From >: ## Rust RFC: opt-in builtin traits In today's Rust, there are a number of builtin traits (sometimes called "kinds"): `Send`, `Freeze`, `Share`, and `Pod` (in the future, perhaps `Sized`). These are

Re: [rust-dev] RFC: Opt-in builtin traits

On Fri, Feb 28, 2014 at 08:15:18PM +0100, Matthieu Monrocq wrote: > Maybe one way of preventing completely un-annotated pieces of data would be > a lint that just checks that at least one property (Send, Freeze, ...) or a > special annotation denoting their absence has been selected for each > publ

Re: [rust-dev] RFC: Opt-in builtin traits

On Fri, Feb 28, 2014 at 09:38:18PM +0100, Matthieu Monrocq wrote: > The main issue with the lint as you proposed is that if I *want* a linear > type without any property, the lint will continuously bug me. Thus the idea > of #[deriving(None)] (or whatever name) to shut the lint down, because once >

Re: [rust-dev] RFC: Opt-in builtin traits

On Fri, Feb 28, 2014 at 10:36:11PM +0100, Gábor Lehel wrote: > I don't see the difference here. Why do you think this should be handled > differently? To be honest I hadn't thought about it before. I agree there is no fundamental difference, though there may be a practical one. I have to mull thi

Re: [rust-dev] RFC: Opt-in builtin traits

On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote: > I'm also slightly concerned that #[deriving(Data)] gives the > impression that there's a trait Data, so maybe that should be > lowercased as in #[deriving(data)], or even just > #[deriving(builtin)], but this is a lesser concern and s

Re: [rust-dev] "Virtual fn" is a bad idea

First off, it'd probably be best to wait to have this discussion until the RFC is available, so that we can be sure we're all commenting on the same thing. The current design evolved after many hours of discussion about the precise performance requirements we wanted to meet as well as exploring the

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

On Wed, Mar 12, 2014 at 03:12:16PM -0400, Clark Gaebel wrote: > That implies we need better editors. Things I need for exploring large > codebases: > > 1. Go to definition > 2. What's the type of this variable/function? FWIW, ctags (with etags-select [1]) gives me both of these things today to an

Re: [rust-dev] Refactor json.rs

Just FYI, I have been working on resolving this issue, but don't have time to write up my intermediate thought process at the moment. Sorry. Hopefully soon. :) Niko On Sat, Mar 22, 2014 at 10:24:51PM +0800, Edward Wang wrote: > Hi, > > I'm in the process of fixing a `ty_trait` variance inferenc

Re: [rust-dev] Reminder: ~[T] is not going away

On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote: > I have no sane proposal to fix this beyond passing a size to free. I don't believe there is a problem with just not using null to represent such pointers (for example, 1 would suffice). This does impose some additional burdens on slic

  1   2   3   4   5   6   >