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
16 matches
Mail list logo
