On 07/26/2014 12:56 PM, Patrick Walton wrote:
Well, part of the problem here is that people are going to want to write
generic functions that take addable values. If we start making `+` and
friends overloadable/ad-hoc, then people are going to be surprised when
they can't pass (say) bignums to
On 26/07/14 12:56 PM, Patrick Walton wrote:
On 7/26/14 5:54 AM, SiegeLordEx wrote:
While this doesn't matter for the pow function (the alternate function
would just have a different path/name), it matters for the special
syntaxes. When the Iterator is no longer enough for you (there was a
std::num::pow is not the most general exponentiation function but a
second-rate utility function in the standard library - you don't have to
use it.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[The previous message got sent accidentally by gmail]
However, for performance reasons, I think some kind of trait overloading
would be nice.
i.e., you should be able to do
implT TraitT for Aφ { ... }
overload impl Traitint for Aφ[int/T] {
//...
}
And when using (x : Traitint) the
On 2014-07-24 16:30, Kevin Ballard wrote:
On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote:
On 2014-07-21 19:17, Patrick Walton wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton pcwal...@mozilla.com wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a
Hi Patrick,
If the signature is wrong and we mistakenly freeze it, we can just introduce
a new function with a different name.
But this is a severe design issue, to introduce new function names. This makes
generic programming impossible. Now the user has to distinguish between
the types, but
On 07/24/2014 06:46 PM, Gregor Cramer wrote:
1. Overloading is not supported (even the archaic C++ is providing this).
I should note that Rust provides a limited form of overloading via the
trait-double dispatch trick:
trait PowImplRes
{
fn pow(self, exp: uint) - Res;
}
fn powRes,
Hi all,
I have an idea about data types here.
We have two `product types` here, tuples and structs, but only one `sum types`,
which is `enum`.
The tuple's members have anonymous names. There is a missing type which is `sum
type`with anonymous members.
Why shouldn't we have another simpler
Hi Marijn,
Firstly, blanket statements like This makes generic programming
impossible and it does not allow proper software design are
unneccesary hyperbole, and do not help the discussion in any way.
You're not right, my statement wasn't blanket, it was my result
after I tried to overwork
For the specific issue of exponentiation, you might be interested in
https://github.com/rust-lang/rfcs/pull/172
On Fri, Jul 25, 2014 at 9:26 AM, Gregor Cramer rema...@gmx.net wrote:
Hi Marijn,
Firstly, blanket statements like This makes generic programming
impossible and it does not
Sorry... I meant a^8 xD...
And overlaoding is not a great concept in general, IMO.
What Rust could do is copy template specialization. So that I can say:
pub fn powT: One + MulT, T(mut base: T, mut exp: uint) - T; //
uses the exponential trick
pub fn powi64(mut base: i64, mut exp: uint) - i64;
On 7/25/14 6:26 AM, Gregor Cramer wrote:
And so the function call is as expected, like with other numeric types:
pow(a) // a is BigInt
But there is now a problem in this function definition, BigInt is given as
a copy, and this is a software design issue (superfluous memory allocation).
And
On 7/25/14 4:43 AM, SiegeLordEx wrote:
Yes, I concur on most of these points and I've brought up some related
points before. The operator overloading technique used by Rust is
antithetical to efficient generic code. The core numeric traits and
functions are currently designed only with built-in
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that calls
`pow` and works optimally with both bigints and
ints. I think the only thing that would work is
something like C++
Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn powT: HasPow(base: T, exp: uint) - T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) - Self
}
Or, just use HasPow in your code.
Why
On 7/25/14 10:11 AM, Oscar Boykin wrote:
Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn powT: HasPow(base: T, exp: uint) - T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) -
On 7/25/14 10:10 AM, Josh Haberman wrote:
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that calls
`pow` and works optimally with both bigints and
ints. I think the only thing
Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn powT: HasPow(base: T, exp: uint) - T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) - Self
}
Or, just use HasPow in your
I gave up at all. (I'm doing software design and implementation since
more than 30 years, and I never accept compromises, this is the way
how to develop magnificient software).
Hum, I would almost strongly disagree I would even go as far as
saying that you won't develop any kind ...
On Fri, Jul 25, 2014 at 3:36 PM, Gregor Cramer rema...@gmx.net wrote:
I don't care about the capabilities of other languages, I don't use a
language if it is not appropriate.
Appropriate for what? You seem to be claiming that stable code in
general needs this feature, so that's consigning all
How can you disagree about what I'm doing?
I don't. I disagree with that: I never accept compromises, this is
the way how to develop magnificient software
Because it's not. Unless you use magnificient only in academic context.
I don't care about the capabilities of other languages, I don't
And of course it's possible to change something to a trait after the
fact without breaking API compatibility.
How you are doing this? I'm in fact a newbie in Rust, and it's interesting
that this can be done. std::num::pow() is a good example, I think.
Suppose I already have a program which is
On Fri, Jul 25, 2014 at 1:45 PM, Gregor Cramer rema...@gmx.net wrote:
How you are doing this? I'm in fact a newbie in Rust, and it's
interesting
that this can be done. std::num::pow() is a good example, I think.
Suppose I already have a program which is using std::num::pow() with a
self
I disagree with that: I never accept compromises, this is
the way how to develop magnificient software
Because it's not. Unless you use magnificient only in academic context.
? I'm not doing academic things.
It's not so much about wether or not overloading could be used in rust
without
On Fri, Jul 25, 2014 at 10:34 AM, Patrick Walton pcwal...@mozilla.com
wrote:
On 7/25/14 10:10 AM, Josh Haberman wrote:
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com
wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that
On 7/25/14 3:20 PM, Josh Haberman wrote:
Got it. So the ad hoc part refers to having a template parameter, but
not being able to check its capabilities/interface at template
parsing/typechecking time, it sounds like?
Right. (The term comes from Making Ad-Hoc Polymorphism Less Ad-Hoc,
which is
On 7/25/14 8:26 PM, Patrick Walton wrote:
Uniform value representations work well too (as
OCaml shows), but of course you'll pay a performance cost for that.
Oh, note that Greg's notes are a little bit out of date when discussing
the performance tradeoffs of uniform value representation. On
Added it to the calendar, and gave you write access so you can add future
events yourself :)
On Wed, Jul 23, 2014 at 10:44 PM, Paul Nathan pnathan.softw...@gmail.com
wrote:
Seattle has a Rust meetup Monthly. Second Monday of the month, 7pm.
There's a event signup on Eventbrite.
In August
Hello Rustaceans,
The next London meetup is on August 14. Come and say hi! Nick Cameron
a.k.a nrc will be giving a talk on DST.
http://www.meetup.com/Rust-London-User-Group/events/196222722/
We’re also looking for speakers for this or future events. Let me know
if you’re interested!
Hi Simon,
I and @farcaller where thinking to prepare a talk on Zinc project
(http://zinc.rs/).
What length of the talks you guys do?
Cheers,
--
Ilya
On 24 July 2014 09:00, Simon Sapin simon.sa...@exyr.org wrote:
Hello Rustaceans,
The next London meetup is on August 14. Come and say hi!
On 24/07/14 10:18, Ilya Dmitrichenko wrote:
Hi Simon,
I and @farcaller where thinking to prepare a talk on Zinc project
(http://zinc.rs/).
That looks cool. Do you want to present on August 14?
What length of the talks you guys do?
The length is flexible, this is only the second time
On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote:
On 2014-07-21 19:17, Patrick Walton wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton pcwal...@mozilla.com wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a language design perspective, maybe it would
Hey all,
Sounds good ! If you wish to present at the event on August 14, then could
you please let us know a title of the presentation and a brief description
of what it will involve so as to let attenders know.
Thank you,
Theo
On Thu, Jul 24, 2014 at 3:05 PM, Simon Sapin simon.sa...@exyr.org
Hi,
Could you provide a link to Patrick's description of size/alignment-passing
implementation? I'm interested in these things.
Well, there could be a warning if the compiler switches to such an
implementation. It's arguably still better than not compiling at all.
However, I don't have enough
On 24/07/14 11:59 AM, Lionel Parreaux wrote:
I can't pronounce myself about the suitability of features in the Rust
language, but it may be worth noting that some convenient high-level
features are already present in the language, like garbage collection.
There isn't an implementation of
I'm really looking forward to this!
On 07/24/2014 02:18 AM, Ilya Dmitrichenko wrote:
Hi Simon,
I and @farcaller where thinking to prepare a talk on Zinc project
(http://zinc.rs/).
What length of the talks you guys do?
Cheers,
___
Rust-dev mailing
Hello Rust folk!
I am new to Rust, and I have doubts concerning current language concepts.
One example: in module ::std::num function pow() is defined:
pub fn powT: One + MulT, T(mut base: T, mut exp: uint) - T {
if exp == 1 { base }
else {
let mut acc = one::T();
while
On 25/07/14 08:46, Gregor Cramer wrote:
Probably in this case it might be a solution to move pow() into a
trait, but
I'm speaking about a general problem. Rust 1.0 will be released, and
someone
is developing a new module for version 1.1. But some of the functions
in 1.0
are inadequate
On 07/24/2014 05:55 PM, Huon Wilson wrote:
1.0 will not stabilise every function in every library; we have precise
stability attributes[1] so that the compiler can warn or error if you
are using functionality that is subject to change. The goal is to have
the entirety of the standard library
On 7/24/14 3:46 PM, Gregor Cramer wrote:
Probably in this case it might be a solution to move pow() into a trait, but
I'm speaking about a general problem. Rust 1.0 will be released, and someone
is developing a new module for version 1.1. But some of the functions in 1.0
are inadequate for the
On 25/07/14 09:21, Tommy M. McGuire wrote:
On 07/24/2014 05:55 PM, Huon Wilson wrote:
1.0 will not stabilise every function in every library; we have precise
stability attributes[1] so that the compiler can warn or error if you
are using functionality that is subject to change. The goal is to
** Please Confirm Subscription
Yes, subscribe me to this list.
(http://steveklabnik.us2.list-manage.com/subscribe/confirm?u=31556dd6d5e1f7d449288b7d9id=3bc3472c3ee=4b68f345fe)
If you received this email by mistake, simply delete it. You
Your subscription to our list has been confirmed.
For your records, here is a copy of the information you submitted to us...
* Email Address: rust-dev@mozilla.org
* First Name:
* Last Name:
If at any time you wish to stop receiving our emails, you can:
unsubscribe here
Sorry, all. I have a weekend project which has a mailchimp email signup on
the home page, and apparently someone went and signed up rust-dev.
What a weird coincidence.
___
Rust-dev mailing list
Rust-dev@mozilla.org
Hey there,
I'm still quite new to Rust. Until now I was able to fix all my bugs by
writing tests and/or randomly adding lifetime parameters to keep the
compiler happy. Now I've hit my first stack overflow. I assume it's due to
the fact that I've screwed up the lifetimes and the objects live too
It is unlikely to be a lifetimes thing; far, far more likely to be a
normal infinite recursion. The size of the stack frame of each
function is fixed at compile time, so the way to blow the stack is by
calling a lot of functions deeply, e.g. it's not possible to write a
loop that places more
Hey Huon,
thanks for the help. The problem is really obvious now that you mention it!
Thanks for the debugging tips however. Coming from Ruby all I ever use are
print statements. So it's good to know how to do it!
Urban
On Wed, Jul 23, 2014 at 10:02 AM, Huon Wilson dbau...@gmail.com wrote:
Could you use RAII to call a lambda?
On 22 July 2014 20:31, Vladimir Pouzanov farcal...@gmail.com wrote:
One note on why there's no after_each:
You cannot really make sure that the epilogue is being called, so if you
need to do anything after your test case, use RAII in before_each.
On
It's great to see Hamcrest ported to Rust.
On 22 July 2014 20:06, Vladimir Pouzanov farcal...@gmail.com wrote:
I've just published a tiny test framework: shiny at
https://github.com/farcaller/shiny. It's best used with hamcrest-rust.
This library exists because I find it ugly to redefine
I'm having an issue with creating a separate testing file for a program I'm
writing. I have a file called 'myprogram.rs', which imports complex numbers
with the following
extern crate num;
use num::complex::Complex;
and then defines a bunch of functions. I want to test these functions in a
On 2014-07-21 19:17, Patrick Walton wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton pcwal...@mozilla.com wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a language design perspective, maybe it would be more
intuitive to
have different syntaxes for copy and move,
Seattle has a Rust meetup Monthly. Second Monday of the month, 7pm.
There's a event signup on Eventbrite.
In August there will be pizza. :)
On Jul 23, 2014 2:22 PM, Erick Tryzelaar erick.tryzel...@gmail.com
wrote:
Good afternoon Rustaceans!
I just created a community calender for all the
I'd also like to see semver stay in the language.
On Jul 21, 2014 7:43 PM, Steve Klabnik st...@steveklabnik.com wrote:
I like the idea of SemVer being in the language itself, personally.
___
Rust-dev mailing list
Rust-dev@mozilla.org
Can there be two simultaneous implementations of a generic trait? I ask
because I want to extend the Complex class to allow for multiplication by
scalars, so that you can use a * b where a and b can be either
scalars or Complex.
The Complex struct already has an implementation of the Mul trait. I
Not right now. Extending the language to allow this is the subject of
RFC 24: https://github.com/rust-lang/rfcs/blob/master/active/0024-traits.md
On Tue, Jul 22, 2014 at 9:50 AM, Allen Welkie allen.wel...@gmail.com wrote:
Can there be two simultaneous implementations of a generic trait? I ask
Hi Felix,
Just now got a doubt. Since we know the type of enum during compile time,
is it not possible to get the value from enum. Something like this..
enum MyTypes{
MyBool(bool),
MyStr(String),
MyInt(int)
}
let a = MyBool(true);
a.get_value(); // trait for enum
let b =
Hi,
So traits seem to be quite similar to Haskell's classes, being also used
for parametric polymorphism. Now, Haskell classes are usually implemented
using runtime dictionary passing. In general, code cannot be specialized
for every function call, since there may be an unbounded number of
You can avoid monomorphization by using trait objects, which erase
the precise implementing type through a vtable + pointer.
http://doc.rust-lang.org/tutorial.html#trait-objects-and-dynamic-method-dispatch
has some documentation.
On Tue, Jul 22, 2014 at 10:16 AM, Lionel Parreaux
Am 22.07.2014 18:50, schrieb Allen Welkie:
Can there be two simultaneous implementations of a generic trait? I ask
because I want to extend the Complex class to allow for multiplication by
scalars, so that you can use a * b where a and b can be either
scalars or Complex.
[snip]
Something
this remindes me of the issue i got when trying to implement finger
trees in Rust so long ago
https://github.com/rust-lang/rust/issues/8613
I suggested to let add a way to specify (in the code) how match
functions do we want to generate and failing at runtime when the limit
is reached. This made
On 7/22/14 10:16 AM, Lionel Parreaux wrote:
I'm not sure whether this is a big problem in practice, but I was
wondering if it would be possible to switch to some runtime mechanism in
cases like this. Maybe we could make a special version of every generic
functions, that takes a dictionary at
I've just published a tiny test framework: shiny at
https://github.com/farcaller/shiny. It's best used with hamcrest-rust.
This library exists because I find it ugly to redefine all the
initialisation code in every test case and I can't simply move it to a
function due to problems with moving [T]
Dude, that's pretty much rspec ;) sweet!
On 22 Jul 2014 20:07, Vladimir Pouzanov farcal...@gmail.com wrote:
I've just published a tiny test framework: shiny at
https://github.com/farcaller/shiny. It's best used with hamcrest-rust.
This library exists because I find it ugly to redefine all the
Nice to see an RSpec-like test framework and Hamcrest assertions/matchers
for Rust!
On Tue, Jul 22, 2014 at 9:09 PM, Ilya Dmitrichenko errordevelo...@gmail.com
wrote:
Dude, that's pretty much rspec ;) sweet!
On 22 Jul 2014 20:07, Vladimir Pouzanov farcal...@gmail.com wrote:
I've just
One note on why there's no after_each:
You cannot really make sure that the epilogue is being called, so if you
need to do anything after your test case, use RAII in before_each.
On Tue, Jul 22, 2014 at 8:10 PM, Benjamin Gudehus hasteb...@gmail.com
wrote:
Nice to see an RSpec-like test
Patrick Walton pcwal...@mozilla.com wrote:
On 7/21/14 2:22 PM, Tobias Müller wrote:
We discussed this with Bartosz literally for weeks (him being a fan of
auto_ptr for too long, later completely converted against it and I take
credit for that :o)). With auto_ptr this was possible:
On Mon, Jul 21, 2014 at 2:45 PM, Patrick Walton pcwal...@mozilla.com
wrote:
... in C++. Not in Rust. That's because, unlike C++, Rust is designed
from the ground up to support moves and copies in a first class way.
As a C++ dev, I feel the need to say THANK YOU for that. Rust being
designed
On 23/07/14 07:10, Tobias Müller wrote:
... in C++. Not in Rust. That's because, unlike C++, Rust is designed
from the ground up to support moves and copies in a first class way.
It's just strange that you can change the semantic of an already existing
operation just by adding new
On 2014-07-21 06:06, Patrick Walton wrote:
On 7/20/14 9:04 PM, Patrick Walton wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
Cool, thanks for the answer. These restrictions seem somewhat complex.
They are required. Otherwise we would end up with a C++-like situation
where copies end
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton pcwal...@mozilla.com wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a language design perspective, maybe it would be more intuitive to
have different syntaxes for copy and move, like:
As a rust newbie, that aspect aways
Patrick Walton pcwal...@mozilla.com wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
As a rust newbie, that aspect aways makes me a bit nervous. Two quite
different operations with the same syntax and and simply changing a detail
in the struct can be enough to switch between the two.
This is
It would be great to discuss which libraries can be removed from the
main tree, I can see that there had been some progress with liburl
[1], but there appear to be a few other very dubious libraries that
can easily leave outside of the main tree.
The ones I was able to spot so far, would be:
-
I believe it has long been the goal that once we have a robust package
manager, we would start moving everything we could get away with out
of the tree. Cargo is pretty awesome now, and I think we could get
away with moving those out, with the caveat that cargo depends on
semver..
On Mon, Jul 21,
On 7/21/14 2:22 PM, Tobias Müller wrote:
We discussed this with Bartosz literally for weeks (him being a fan of
auto_ptr for too long, later completely converted against it and I take
credit for that :o)). With auto_ptr this was possible:
auto_ptrint a(new int);
auto_ptrint b = a;
It would
On 21 July 2014 22:46, Corey Richardson co...@octayn.net wrote:
Cargo is pretty awesome now, and I think we could get away with moving those
out, with the caveat that cargo depends on semver..
It does have a bunch of things as submodules already. I wouldn't find
it unreasonable to just make
Doing this is a goal, but we're going to need a complete strategy -
let's please not start doing this too hastily. Maintaining crates out of
tree is not easy, and we need to have the systems in place that will let
us succeed (particularly around integration). acrichto will need to be
involved
I expect moving crates out of the main tree to be important for reducing
build cycle time.
On 07/21/2014 02:28 PM, Ilya Dmitrichenko wrote:
It would be great to discuss which libraries can be removed from the
main tree, I can see that there had been some progress with liburl
[1], but there
As to your original question about candidate libs, here are mine:
arena
fourcc
glob
graphviz (with some rustc refactoring)
hexfloat
regex
url
uuid
On 07/21/2014 02:28 PM, Ilya Dmitrichenko wrote:
It would be great to discuss which libraries can be removed from the
main tree, I can see that
I like the idea of SemVer being in the language itself, personally.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I probably picked the exact wrong project for diving into rust, but
I'd like to teach rust how to build powerpc64-bgq-linux binaries.
I've got a powerpc64-bgq-linux toolchain. I added this stanza to
mk/platforms.mk, but cribbed from other platforms. Did I leave out
any important settings?
%
Hi Rob!
It's probably best to way until porting had been simplified.
Here is a ongoing discussion of this matter:
https://github.com/rust-lang/rfcs/pull/131
Cheers,
--
Ilya
On 20 Jul 2014 15:35, Rob Latham rlat...@gmail.com wrote:
I probably picked the exact wrong project for diving into
Hi Rob,
make: *** No rule to make target
`powerpc64-bgq-linux/rt/arch/powerpc64/morestack.o', needed by
`powerpc64-bgq-linux/rt/libsmorestack.a'. Stop.
I don't know how to go about debugging this. Any ideas?
There is no way to debug this - you have to implement a couple of
functions
On Sun, Jul 13, 2014 at 10:37 PM, Nick Cameron li...@ncameron.org wrote:
Yes, this is the right place for meta-discussion.
I'll make sure to be stricter about commenting on the PRs in the future.
The aim of this email is only to summarise the discussion so far, it
shouldn't add new opinions
Hi,
Consider these two examples:
1)
let mut file = File::open(filename);
file.read(buf);
2)
let file = File::open(filename);
let mut reader = BufferedReader::new(file);
reader.read(buf);
My question is: in example 2, why doesn't BufferedReader need file to
be mutable? After all,
That's right. `BufferedReader` takes the `Reader` it wraps by-value,
but the `read` method takes `mut self`. Moving something doesn't
require it to be stored in a mutable variable, but taking a `mut` to
it does.
On Sun, Jul 20, 2014 at 6:29 PM, David Henningsson di...@ubuntu.com wrote:
Hi,
On 7/20/14 6:29 PM, David Henningsson wrote:
Hi,
Consider these two examples:
1)
let mut file = File::open(filename);
file.read(buf);
2)
let file = File::open(filename);
let mut reader = BufferedReader::new(file);
reader.read(buf);
My question is: in example 2, why doesn't BufferedReader
On 2014-07-21 03:33, Patrick Walton wrote:
On 7/20/14 6:29 PM, David Henningsson wrote:
Hi,
Consider these two examples:
1)
let mut file = File::open(filename);
file.read(buf);
2)
let file = File::open(filename);
let mut reader = BufferedReader::new(file);
reader.read(buf);
My question
Because Foo is a POD type (implements the Copy trait). Essentially, types that
can be copied by copying bits only (not allocating) are POD types, and all
others move.
This may be changed with the Opt-In Built-in Traits proposal so that POD types
must be specially declared to implement Copy
Some types are implicitly copyable. They implement the built-in trait Copy.
A type is Copy if it is
a) numeric primitive (e.g. f32 or uint), or
b) an immutable reference (e.g. Foo or str), or
c) a raw pointer (e.g. *const Foo or *mut Foo), or
d) a collection of Copy types (e.g. struct Foo { a:
On 2014-07-21 04:43, Steven Fackler wrote:
Some types are implicitly copyable. They implement the built-in trait
Copy. A type is Copy if it is
a) numeric primitive (e.g. f32 or uint), or
b) an immutable reference (e.g. Foo or str), or
c) a raw pointer (e.g. *const Foo or *mut Foo), or
d) a
On 7/20/14 8:12 PM, David Henningsson wrote:
Cool, thanks for the answer. These restrictions seem somewhat complex.
They are required. Otherwise we would end up with a C++-like situation
where copies end up happening too frequently.
This wasn't very intuitive for me, so just throwing this
On 7/20/14 9:04 PM, Patrick Walton wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
Cool, thanks for the answer. These restrictions seem somewhat complex.
They are required. Otherwise we would end up with a C++-like situation
where copies end up happening too frequently.
Also note that
Is there any prospect of compiling Rust to C anytime in the mid to near future?
This would be a really attractive option for anyone who wants to write
in Rust, but wants the extreme portability of C.
Actually maybe I should first ask if this is actually a tractable
problem. Are there technical
The biggest problem would be probably be handling stack unwinding (IIRC the
LLVM C backend never tried to handle this either). The only option when
targeting C is to use setjmp / longjmp, but that is going to be pretty
inefficient. Alternatively you could just abort instead of unwinding.
On Jul 16, 2014, at 10:54 AM, Gábor Lehel glaebho...@gmail.com wrote:
3. As far as I'm aware, subtyping in the current language arises only from
subtyping of lifetimes. Where is this important? One example was mentioned in
[Niko's recent blog
Hi!
I was thinking about fork/join-style parallelism and about whether
this can be made to work including the possibility to pass references
(or something similar to references) across task boundaries. So far, I
came up with a little low-level building block that could be of
interest to the
On Fri, Jul 18, 2014 at 12:35 AM, Cameron Zwarich zwar...@mozilla.com wrote:
The biggest problem would be probably be handling stack
unwinding (IIRC the LLVM C backend never tried to handle
this either).
Interesting, I can see what that would be a challenge.
The only option when targeting C
On Jul 18, 2014, at 9:52 AM, Josh Haberman jhaber...@gmail.com wrote:
The only option when targeting C is to use
setjmp / longjmp, but that is going to be pretty inefficient.
Why do you think of setjmp/longjmp as inefficient? If you use the
_setjmp/_longjmp variants that don't fiddle with
On Fri, Jul 18, 2014 at 12:29 AM, Josh Haberman jhaber...@gmail.com wrote:
Is there any prospect of compiling Rust to C anytime in the mid to near
future?
This would be a really attractive option for anyone who wants to write
in Rust, but wants the extreme portability of C.
Actually maybe
On 17/lug/2014, at 20:08, Brian Anderson bander...@mozilla.com wrote:
Thanks for your work on MacPorts. Did you use any flags to configure or
arguments to make? What version of OS X, clang/gcc?
Yes, sorry, I’m building this on OS X 10.9.4 with system clang (5.1). After
further inspection, I
601 - 700 of 8896 matches
Mail list logo
