Hello everyone,
I might have found a bug. Ubuntu 12.04 LTS, rust master pulled a few hours
ago.
I've isolated my problem down to the following:
fn main() {
let arr : ~[str] = std::os::args()[1].split_str(::).collect();
std::io::println(first + arr[0]);
std::io::println(first again
On 02/24/2014 10:15 PM, Erick Tryzelaar wrote:
Brian: yes, at the moment `#[deriving(Hash)]` does support more than
SipHash. However this PR temporarily removes that feature to replace
`#[allow(default_type_param_usage)]` with `#[feature(default_type_params)]`:
Hi everyone,
Here with a novice question. I'm trying to use the select! macro in:
http://static.rust-lang.org/doc/0.9/std/comm/select/index.html
And can't figure out how to get it to import. My current code looks like
this:
use std::comm::select;
fn main() {
let (p,c): (Portint, Chanint) =
You can use the prototype through `std::comm::Select` for now, but the
macro is not currently exported. See
https://github.com/mozilla/rust/issues/12044 for more information.
On Mon, Feb 24, 2014 at 10:59 PM, Frank Huang fyhu...@gmail.com wrote:
Hi everyone,
Here with a novice question. I'm
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
I'm in favor.
I guess if there's some giant use case for the current mut then we could
keep it and add this new version as move, but I agree that that probably
isn't the case.
On Tue, Feb 25, 2014 at 10:32 AM, Niko Matsakis n...@alum.mit.edu wrote:
I wrote up an RFC. Posted on my blog at:
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:
I too was under the impression that you could not read from a mutably-borrowed
location.
I am looking forward to the ability to move out of a mut (as long as the value
is replaced again),
if the issues around task failure and destructors can be solved.
-Kevin
On Feb 25, 2014, at 12:19 PM,
Rust now has the ability to import macros from other crates, hurray!
However, I'd like to propose adjusting the current way of using them to be
more like importing/exporting other symbols of a crate.
1) It's more consistent, makes it easier to find where macros came from.
2) Current usage brings
Me three. I thought the last of this reading-while-mut was excised with
the removal of @mut.
If you think you might like to implement this change, though, let me
know. =)
Given generous amounts of hand-holding, I might give it a shot.
On Tue, Feb 25, 2014 at 10:23 PM, Kevin Ballard
This is problematic because name resolutions happens far after macro
expansion. I think this could be doable with an extremely limited
macro module system, but I think it's not-very-good to have the same
path syntax for two incredibly different systems.
On Tue, Feb 25, 2014 at 4:39 PM, Sean
Is this not already expressible with swap/replace? Is there a big
improvement here that I'm missing?
On Tue, Feb 25, 2014 at 4:23 PM, Kevin Ballard ke...@sb.org wrote:
I too was under the impression that you could not read from a
mutably-borrowed location.
I am looking forward to the ability
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.
-Kevin
On Feb 25, 2014, at 3:14 PM, Corey Richardson co...@octayn.net wrote:
Is this not already expressible with swap/replace? Is there a big
Well, you can if you can construct a dummy value to swap in temporarily.
I'm pretty sure that's not always possible without venturing into unsafe
code (like making an uninit block of the proper size or something).
Moreover, nothing stops you from forgetting to swap the value back in so
you could
On Feb 25, 2014, at 4:04 PM, Eric Reed ecr...@cs.washington.edu wrote:
Would a mut that could move enable us to write insertion into a growable
data structure that might reallocate itself without unsafe code? Something
like OwnedVector.push() for instance.
The problem with that is you
True. I guess I was thinking less unsafe code as opposed to no unsafe code.
On Tue, Feb 25, 2014 at 4:47 PM, Kevin Ballard ke...@sb.org wrote:
On Feb 25, 2014, at 4:04 PM, Eric Reed ecr...@cs.washington.edu wrote:
Would a mut that could move enable us to write insertion into a
growable
Hey,
I’m not sure how people feel about Option types but there seem to be a few
hundred uses in the rust codebase. Wanted to share an idea we use in our custom
type system (“Hack”) at Facebook to make it a bit nicer to safely deal with
null references. We don’t use Option types directly. I
I, for one, would really like to see rust steal named and optional
arguments from OCaml. They're a huge boon to code readability.
On Tue, Feb 25, 2014 at 10:24 PM, Aran Donohue a...@fb.com wrote:
Hey,
I’m not sure how people feel about Option types but there seem to be a
few hundred uses
On Tue, Feb 25, 2014 at 11:00 AM, Phil Dawes rustp...@phildawes.net wrote:
fn main() {
let arr : ~[str] = std::os::args()[1].split_str(::).collect();
std::io::println(first + arr[0]);
std::io::println(first again + arr[0]);
}
I am working on an older version of the compiler
Turns out Rust's Option type already has all this behavior, so I think
we're all on to something :)
Option is a little more powerful than nullable pointers because you can
have Options of non-pointer values. IIRC, Option~T is actually compressed
to be a nullable pointer. I actually really like
Turns out Option.and_then is literally Option's monadic bind. Both
do-notation and Haskell's list comprehensions (which generalize to monads
and I think are equivalent to Scala's for-comprehensions) actually just
desugar into calls to the monad's bind and return functions (Option's
return is just
Hi Ashish,
Yes that works fine. Splitting out 'args' into a separate variable fixes
the behaviour.
So this is a lifetime issue and the latest compiler isn't picking it up?
Thanks,
Phil
On Wed, Feb 26, 2014 at 4:23 AM, Ashish Myles marci...@gmail.com wrote:
On Tue, Feb 25, 2014 at 11:00 AM,
This definitely seems to be a bug. If you can, you should file this at
https://github.com/mozilla/rust/issues.
-Kevin
On Feb 25, 2014, at 10:12 PM, Phil Dawes rustp...@phildawes.net wrote:
Hi Ashish,
Yes that works fine. Splitting out 'args' into a separate variable fixes the
behaviour.
Agreed. Exporting macros feels like a hack. Importing macros feels like a hack.
Global namespaces are a pain.
Macros on the whole feel like a second class citizen of the language. I’m not
talking about writing them - I’m perfectly fine about that kind of ugliness –
I’m referring to the client
24 matches
Mail list logo
