On 01/03/14 07:23, 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 somewhat bike-sheddy.
I
I think its great that you are going to be working on this. A
comprehensive datetime library is very important. That said I have not
got any particular ideas or comments.
I have not used Joda time/JSR-310 but the docs look promising and lots
of people seem to recommend it.
Cheers
Gareth
You have done an excellent job. Thank you.
Gareth
On 31/08/13 01:05, Graydon Hoare wrote:
Hi,
As I'm sure many of you who know me are aware, my role as technical
lead on Rust has been quite draining over the years. Both to myself
and to those I've worked with, it just isn't a great fit for
Great work, I like the search already. Thanks!
On 05/08/13 06:53, Corey Richardson wrote:
Hi all,
I'm very excited to announce that rustdoc_ng now extracts and
jsonifies crates completely in their entirety. Yay! Jordi has been
doing some awesome work with the frontend, even adding a search.
On 05/08/13 19:56, Dov Reshef wrote:
If I understand correctly mod foo import the foo module into the
current module, and use foo::bar bring bar from foo module into the
current scope, so it seems more logical that use should follow mod,
not the other way around.
My understanding is that
One downside of external iterators is that they produce function
signatures that expose implementation details and are harder to understand.
For example, an internal iterator function that loops over odd numbers
would have a signature like this:
fn each_odd(ints: [int], fn(int) - bool) -
On 12/06/13 15:58, Niko Matsakis wrote:
I imagine that `for expr |pat| { body }` would be syntactic sugar
for:
let mut _iterator_ = expr;
loop {
let pat = match _iterator_.next() {
None = break,
Some(v) = v
};
body
}
I think
On 25/05/13 20:02, Corey Richardson wrote:
On Sat, May 25, 2013 at 2:36 PM, Gareth Smith
garethdanielsm...@gmail.com wrote:
I am guessing that STALE on http://buildbot.rust-lang.org/bors/bors.html
means needs rebase - right?
Yes
How does a pull request leave the STALE state? Does it have
On 10/05/13 01:45, Graydon Hoare wrote:
On 13-05-07 08:09 AM, Sanghyeon Seo wrote:
Here are some feature requests to bors queue status page at
http://buildbot.rust-lang.org/bors/bors.html
3. OUTDATED state, for pull requests that need to be rebased. GitHub
API provides mergeable attribute for
There might be something obviously wrong with this, but how about:
match foo {
let foo = Foo { field: x } = ...
}
Gareth
On 3 May 2013 02:12, Patrick Walton pwal...@mozilla.com wrote:
Hi everyone,
There's consensus that `@` (imported from Haskell) is a bad binding
operator
On 11/01/13 18:50, Niko Matsakis wrote:
fn fooT:Eq(..) {...} // One bound is the same
fn fooT:(Ord, Eq, Hash)(...) {...} // Multiple bounds require
parentheses
How about using { ... } rather than ( ... ), like imports:
use xxx::{a, b, c};
fn fooT:{Ord, Eq, Hash}(...) { ... }
I don't know
I agree it is confusing and that the proposed syntax would probably be
less so.
But, I think that:
impl Trait for Type { ... }
Is still possible to confuse with:
impl Type { ... }
Because they both start with the same keyword. Though perhaps this is
not significant.
Gareth
Option 3 looks prettiest to me, but I like that in Option 1 the
error-raising code comes before the error-handling code (based on
experience with other languages). This might not be an issue in practice.
I am not sure how I like Option 3 with a more complex trap block:
OutOfKittens.trap(|t|
On 15/10/12 21:31, Graydon Hoare wrote:
Mozilla and the Rust community are pleased to announce version 0.4 of
the Rust compiler and associated tools.
Thanks Graydon and the rest of Mozilla and the others. Rust is shaping
up. :)
Gareth
___
Rust-dev
Hi James,
The pattern matching syntax is pretty consistent with Haskell, Ocaml,
SML and similar-ish statically typed functional languages. I like it
because it is concise and because a pattern is syntactically identical
or at least similar to the the value literals that produce the types
On 05/09/12 21:13, Patrick Walton wrote:
On 9/5/12 1:10 PM, Gareth Smith wrote:
How about having str be represented internally - but not in the type
system - as a pointer to the actual string data. Copying a str would
copy the pointed-to string data in addition to the pointer, so str would
Hi,
I guess this is also an issue when type names are used in non-constructor
functions: e.g. should the to_str method actually be called to_Str, should
to_bytes be called to_Bytes ?
I think the new convention looks OK, but it is a bit weird with multiple
constructors in a module because you
On 15/08/12 20:31, Brian Anderson wrote:
There are two reasons that I can recall off-hand...
That sounds reasonable. Thanks.
Gareth.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Thus this is in practice a backwards-compatible change intended to
eliminate a good deal of toe-stubbing.
IMHO the source of the toe-stubbing may be that rust has so many different
ways to return a value:
fn f() - int { 42 }
or
fn f() - int { ret 42 }
or
fn f() - int { ret 42; }
And ret
On 26/07/12 21:54, Niko Matsakis wrote:
Summary: we plan to make it possible for you to call methods on a
variable of type `fat` even if those methods are defined on `fat`.
But it doesn't work yet...
Thats interesting. Thanks for the explanation.
Gareth
On 25/07/12 21:11, Graydon Hoare wrote:
... the borrowed-pointer-using code looks like so: ...
Thanks for the clarification. That makes sense.
Can I have another clarification please. I have some rust code currently
that looks like this:
// a type that should not be copied implicitly
On 08/07/12 03:35, Niko Matsakis wrote:
Your recent e-mail reminded me that I never responded to this one.
Sorry about that, I was on vacation.
No problem. You deserved a vacation with all the work you are doing on rust.
In general I think the most widely applicable answer is that if you
On 24/06/12 19:51, Niko Matsakis wrote:
Are there other ways of fixing the issue?
There is one other way. You can restructure the caller. The most
ambitious would be to change the field from mutable to immutable, but
often that does not work. In that case, you can also update the
Hurrah! Thank you.
Gareth
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Thanks for the response Niko,
There is one other way. You can restructure the caller. The most
ambitious would be to change the field from mutable to immutable, but
often that does not work. In that case, you can also update the type
of the record from @{mut f: optionT} to @{mut f:
Hi rust-dev,
How should these errors be dealt with?
For example, given the following code:
fn takes_an_option(_x: optionint) {}
fn takes_a_rec(x: @{mut a: optionint}) {
takes_an_option(x.a);
}
fn main() {
let x = @{mut a: some(4)};
takes_a_rec(x);
}
rustc produces:
On 07/06/12 22:27, Patrick Walton wrote:
If you allow all block lambdas to have early returns with ret, then
this:
fn f() {
for int::range(1, 10) |i| {
ret i;
}
}
Has a very different meaning from:
fn f() {
int::range(1, 10) |i| {
On 02/06/12 16:17, Patrick Walton wrote:
I agree completely and have thought the exact same thing in the past.
I will bring this up at the next meeting.
On 04/06/12 01:52, Brian Anderson wrote:
Agreed on all points. The current syntax was just an expedient to get
rustdoc working, and the
Dear Rust developers/users,
I want to convince you that the current syntax for doc-comments in rust
is sub-optimal and should be re-worked.
Here is an example of a doc-comment in various languages:
Rust:
#[doc = Some short description of what this function does]
fn my_fun (x: int) -
On 10/05/12 15:57, Graydon Hoare wrote:
I'm a little nervous about what you're proposing here. I think enums
can probably be done with a sys::enum_valueT intrinsic that fails to
compile on non-enums. Or something involving the reflection interface
I'm currently building. I don't think this
On 10/05/12 15:57, Graydon Hoare wrote:
I'm a little nervous about what you're proposing here. I think enums
can probably be done with a sys::enum_valueT intrinsic that fails to
compile on non-enums. Or something involving the reflection interface
I'm currently building. I don't think this
On 30/04/12 07:08, Steven Blenkinsop wrote:
On Sunday, April 29, 2012, Gareth Smith wrote:
Hi,
I have written up some thoughts about a enabling a less
repetitious API for constructing hashmaps (amongst other
possibilities), here:
https://github.com/mozilla/rust/wiki
Hi,
I have written up some thoughts about a enabling a less repetitious API
for constructing hashmaps (amongst other possibilities), here:
https://github.com/mozilla/rust/wiki/Bikeshed-impl-method-extraction
Does this make any sense?
Gareth
___
33 matches
Mail list logo
