For one, the Index trait is in dire need of an overhaul.
In respect to the operator traits in general, I have actually been thinking of
submitting an RFC proposing that they take thier parameters by-value instead of
by-ref. That would remove the auto-ref behaviour of the operators which is more
On 29 Mar 2014, at 2:12 pm, Tony Arcieri basc...@gmail.com wrote:
Recently there has been a call to introduce an optional feature flag which
removes bounds checks to the *safe* subset of Rust (i.e. outside of unsafe
blocks)
I think this sort of suggestion imperils Rust's goals as a
This is incredible news. Thank you for agreeing to help us out in our time of
need!
I have a couple of questions:
- For those of us who are less familiar with Bundler, could you offer a quick
run-down of how it works?
- Are there any things you learned from doing Bundler that you would do
Would be interesting to see the repository history rendered in gource:
https://code.google.com/p/gource/ (obviously with all the ugly bloom effects
turned off). I had it running for a little yesterday, but I needed to do some
tweaking of how the file names were shown - things were getting very
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
We should probably start using the #[deprecated] attribute more. Using it to
phase things out in the std is currently annoying because we have the
#[deny(deprecated)] attribute on.
~Brendan
On 19 Feb 2014, at 12:40 pm, Brian Anderson bander...@mozilla.com wrote:
Hey there.
I'd like to
On 15 Jan 2014, at 9:35 am, Eric Reed ecr...@cs.washington.edu wrote:
I'm skeptical about combining Chan and SharedChan. Maintaining that
distinction is useful for expressing the programmer's intent and would
certainly make any analysis that cared to distinguish between single and
multiple
On 13 Jan 2014, at 12:34 am, Owen Shepherd owen.sheph...@e43.eu wrote:
But I also feel that by making the unchecked ones the shorter name, the
language would be implicitly sending a message that they're preferred.
Custom operator time!
Say hello to our checked operators:
trait
On 11 Jan 2014, at 9:38 am, Don Question donquest...@rocketmail.com wrote:
2. I'm used to curly braces, but every time i have to code in C or JavaScript
i miss the
better readability of python's curly-free syntax. What was the reason to keep
the (imho:
annoying) curly braces? I must
struct Foo([f64, ..3]);
implI: Int IndexI, f64 for Foo {
fn index(self, index: I) - f64 {
let index = index.to_uint().unwrap();
match self {
Foo(ref v) = v[index].clone()
}
}
}
fn main() {
let tmp : uint = 0;
let foo = Foo([1.0, 2.0, 3.0]);
On 19 Dec 2013, at 10:03 pm, Felix S. Klock II pnkfe...@mozilla.com wrote:
rust-dev-
From reading the article, I thought the point was that a universal server
could be deployed and initiated before the actual service it would offer had
actually been *written*.
Ah, that makes more sense
On 19 Dec 2013, at 1:26 am, Benjamin Striegel ben.strie...@gmail.com wrote:
Hello rusties, I was reading a blog post by Joe Armstrong recently in which
he shows off his favorite tiny Erlang program, called the Universal Server:
On 19 Dec 2013, at 5:17 am, Kevin Ballard ke...@sb.org wrote:
That's cute, but I don't really understand the point. The sample program he
gave:
test() -
Pid = spawn(fun universal_server/0),
Pid ! {become, fun factorial_server/0},
Pid ! {self(), 50},
receive
X -
On 15 Dec 2013, at 1:39 am, Jack Moffitt j...@metajack.im wrote:
Some botnet is picking on #rust. Until the situation is resolved[1] or
the botnet gives up, we've been turning on moderation in the #rust IRC
room.
This means that you won't be able to join #rust or talk in the channel
On 7 Dec 2013, at 10:47 am, Simon Sapin simon.sa...@exyr.org wrote:
This is why we have methods like .map() and .and_then()
I like using these higher order functions, but I run into lots of issues with
moved values because we don’t have once functions. I end up having to use
matches, which
, but that will probably be
post 1.0.
(I might be getting a little off-topic here)
~Brendan
On 7 Dec 2013, at 5:27 pm, Brendan Zabarauskas bjz...@yahoo.com.au wrote:
I’m not sure I understand everything in your post, but this is how I’d write
you first C++ example:
struct NumbersIV, FV
On 5 Dec 2013, at 1:46 pm, Patrick Walton pcwal...@mozilla.com wrote:
The particular criticisms of the Scala compiler, that the front-end does too
much desugaring and that code is a string, are definitely not true for the
Rust compiler. (Well, OK, `for` is desugared too early, but that has
On 30 Nov 2013, at 6:55 pm, spir denis.s...@gmail.com wrote:
Since this issue is all about placing something into memory, why not use
'mem' ?
Denis
Some folks have suggested using `alloc`.
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 30 Nov 2013, at 5:34 pm, Oren Ben-Kiki o...@ben-kiki.org wrote:
I find `do` syntax form is vital for DSL-ish code. Getting rid of it makes a
lot of code look downright ugly. I'd rather it used a more Ruby-ish notation
though, I find that putting the `do` far away from the `{ ... }`
On 1 Dec 2013, at 1:45 pm, Patrick Walton pcwal...@mozilla.com wrote:
the experiment of using blocks in place of RAII for stuff like with_c_str
or unkillable has failed: it leads to too much rightward drift.
Patrick
I guess I can agree with that. I remember when I first started with Rust
Personally I'd appreciate a type system that's able to express SI units,
which C++ and Haskell are powerful enough to do[1].
I agree. This is of huge importance when it comes to providing compile time
safety guarantees. And if the language is powerful enough to express SI units,
then it also
SML also shares these semantics when it comes to bindings. That is, a
subsequent binding to the same identifier can ‘mask’ those that proceed it,
even if they are in the same scope and the bound values are of different types.
Once a value has had its identifier masked, it can no longer be
On 12 Nov 2013, at 10:21 am, Gaetan gae...@xeberon.net wrote:
- as a typicial rust programmer, will i see the usage of str or ~str as
logic or will i have to copy paste some sample code each time because it
works this way in rust”
This is what I thought at first, but once you use it for a
On 12 Nov 2013, at 10:12 am, John Clements cleme...@brinckerhoff.org wrote:
If you had the energy to build an alternate front-end using a parenthesized
syntax, I'm sure there are others that would give it a try. Me, for instance!
It would be nice if we could:
- A: desugar Rust into a small
You’re trying to move the ~strs out of the vector. You’ll need to use
`move_iter`:
~~~
let ports = do myvect.move_iter().map |s| {
let (pport, cchan) = stream();
do spawn {
cchan.send(fun(s))
}
pport
}.to_owned_vec();
~~~
Also note the use of `to_owned_vec`. `map` lazily
capable optimizing the code,I wouldn't want an option
struct to be created each time I call this function.
What would be the way to verify that llvm did the job correctly?
Cheers
Remi
On Oct 28, 2013 11:12 PM, Brendan Zabarauskas bjz...@yahoo.com.au wrote:
Yes, it's a static cast, so
struct ntimesT(times: uint, value: T) - T;
Does this syntax work at the moment?
~Brendan
On 29/10/2013, at 9:33 PM, Niko Matsakis n...@alum.mit.edu wrote:
Incidentally, my preferred way to return a closure is to use
an impl like so:
struct ntimesT(times: uint, value: T) - T;
Yes, it's a static cast, so llvm should optimise that out.
Do note however that the API has changed in 0.9-pre, and num::cast now returns
an OptionT. So your code would be:
~~~
let res: T = aVariable / num::cast(2).unwrap();
~~~
LLVM should resolve the conditional at statically - I haven't
Using master is highly recommended. Treat the 0.* releases as snapshots as
opposed to stable releases.
~Brendan
On 26/10/2013, at 11:59 PM, Ramakrishnan Muthukrishnan vu3...@gmail.com wrote:
On Sat, Oct 26, 2013 at 5:00 PM, Ramakrishnan Muthukrishnan
vu3...@gmail.com wrote:
Hi,
This is
chain-oriented APIs (methods like `fn frob(self) - Frob`)
What about:
~~~
fn frob(self) - Frob {
let mut x = self;// not sure if you need `cast::transmute_mut` here
x.thing = foo();
x
}
~~~
That would solve the 'copying' problem.
I was actually considering doing this as a way
options at the `extern mod` line in your source code.
If you have any issues, questions or suggestions, you can contact me on
irc.mozilla.org #rust-gamedev[2]. My
handle is 'bjz'.
Hopefully this helps to give Rust an extra boost in the realm of
high-performance graphics!
Regards,
Brendan
I normally prefer using `std::num::{cast, zero}` as its a tad more readable. So:
use std::num;
fn averageT:Int(values: [T]) - T {
values.iter()
.fold(num::zero::T(), |x, y| x.add(y))
.div(num::cast(values.len()))
}
fn main() {
Adding struct members in traits would be… weird. Where would those members be
stored when passing things around by value?
This sounds like something for properties. But as Nikko says it is not a
planned feature at the moment – there is enough on the table for 1.0 as it is.
I'm sure they would
Congratulations! You've already made some significant contributions to Rust,
and we greatly appreciate your efforts. Could think of nobody better to be
working on Rust full time.
~Brendan
On 17/09/2013, at 6:43 AM, Alex Crichton acrich...@mozilla.com wrote:
Greetings rust-dev! I wanted to
Has anybody worked out a decent way to lay out complex definitions? This is
what I'm starting to do:
pub trait AffineSpace
S: Field,
V: VectorSpaceS
: Eq
+ Zero
+ AddV, Self
+ SubSelf, V
+ ScalarMulS
{
// ...
}
impls are harder
My understanding is that Rust is meant more for real-time, performance/security
critical applications, such as user-facing guis and rendering engines. This
also fits nicely with games and graphics applications. There is also the real
possibility of it being useful in embedded systems. Go is
I definitely find this very lovely. Lining up with the tab stops perfectly is a
big plus.
~Brendan
On 26/08/2013, at 11:21 PM, Armin Ronacher armin.ronac...@active-4.com wrote:
Hi,
On 26/08/2013 02:59, Corey Richardson wrote:
C:
The nice thing about this solution is that with the
This would be amazing. At the moment the [T,..n] types are pretty damn useless
when it comes to generics.
Mathematics, science and units of measure libs would find constant
parametrisation most useful.
I could imagine something like:
fn dotT: Ring, N: uint(a: [T, ..N], b: [T, ..N]) - T { … }
That was my understanding. Without knowing much about the compiler, `mod` seems
to declare an item. It would be weird to allow imports between item
declarations.
~Brendan
On 06/08/2013, at 5:53 AM, Gareth Smith garethdanielsm...@gmail.com wrote:
On 05/08/13 19:56, Dov Reshef wrote:
If I
On 03/08/2013, at 12:25 PM, Jeaye je...@arrownext.com wrote:
To be fair, and I like being fair, both of these are inconsistent within
Rust. If functions_are_like_this then types Should_Be_Like_This or
Maybe_like_this.
Having different significantly different styles for types, functions
On 31/07/2013, at 7:29 AM, Graydon Hoare gray...@mozilla.com 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 dictatorial and less democratic when it comes to
such things; I'm a bit of
This would make function signatures harder to read in some instances,
particularly when using closures and higher-order functions:
let f: fn(T): T = …;
fn hofT(x: T, f: fn(T): T): fn(T): T { … }
Compare to the current syntax:
let f: fn(T) - T = …;
fn hofT(x: T, f: fn(T) - T)
On 25/07/2013, at 2:15 AM, Evan Martin mart...@danga.com wrote:
Is an Optionu8 implemented as a pair of (type, value) or is it packed into
a single word?
A quick test shows:
rusti std::sys::size_of::Optionu8()
16
~Brendan___
Rust-dev
Just so folks have the heads up, here is the discussion of the blog post on
reddit: http://www.reddit.com/r/rust/comments/1igvye/vision_for_rust_simd/
~Brendan
On 16/07/2013, at 2:27 PM, Jens Nockert j...@nockert.se wrote:
Hello rust-dev!
I implemented OpenCL-style[0] accessors for SIMD
Introducing a new t, ty_simd_vec(t, uint), instead of using the current
#[simd] struct { … }, is yet another thing that is controversial about the
patch
This is indeed a shame because named fields are very nice for clean,
self-documenting apis. Perhaps properties solve this, but I don't
, at 12:13, Brendan Zabarauskas bjz...@yahoo.com.au wrote:
Introducing a new t, ty_simd_vec(t, uint), instead of using the current
#[simd] struct { … }, is yet another thing that is controversial about the
patch
This is indeed a shame because named fields are very nice for clean,
self
wrote:
On Sun, Jul 14, 2013 at 03:51:25PM +1000, Brendan Zabarauskas wrote:
I'm a fan of sticking with the fmt! style - it separates the data
from the representation as opposed to mixing the two. But maybe I'm
just an old fuddy-duddy.
+1 for format strings, though I'm not wedded to the precise
print!()/println!() and printf!()/printfln!() sounds good to me. Adding an
extra 'f' isn't much of a hassle for fmt! functionality.
~Brendan
On 16/07/2013, at 7:25 AM, Steven Ashley ste...@ashley.net.nz wrote:
A possible use case for printfln may be to ensure that a new line is always
PM, Brendan Zabarauskas
bjz...@yahoo.com.au wrote:
print!()/println!() and printf!()/printfln!() sounds good to me. Adding an
extra 'f' isn't much of a hassle for fmt! functionality.
Way I see it is if I can type less than `println(fmt!(%?, foo));`,
I'm happy :) That is basically the only
Actually, your suggestion would actually be quite nice for quit print
debugging. often I doe want to just do: `println(x)`. What about:
- print!, println! - comma separated list of values, converted to a string
- printf!, printfln! - wraps fmt!
Simples.
~Brendan
On 14/07/2013, at 12:39 PM,
.. no new languages have used it in ages
http://golang.org/pkg/fmt/
On 14/07/2013, at 4:29 PM, Bennie Kloosteman bkloo...@gmail.com wrote:
The C printf way is very primative .. no new languages have used it in
ages and even C++ tried to replace it with cout and overloading .
I
Not to mention all the allocation that goes on in num::strconv :/
Some work on that could possibly result in a speed up.
I'm a fan of sticking with the fmt! style - it separates the data from the
representation as opposed to mixing the two. But maybe I'm just an old
fuddy-duddy.
~Brendan
On
52 matches
Mail list logo
