If I get it right, calls to traits are resolved in runtime (so, traits are
kind of similar to C++ virtual methods).
What I'm proposing here is a compile-time approach.
Let's say we have the following trait:
pub trait LCD {
fn line(mut self, x0_b: i32, y0_b: i32, x1: i32, y1: i32, color: u8);
On 02/04/14 06:25 AM, Vladimir Pouzanov wrote:
If I get it right, calls to traits are resolved in runtime (so, traits
are kind of similar to C++ virtual methods).
All method calls on regular types are resolved via static dispatch,
whether or not they come from a trait. For example, consider a
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely remove many uses of
~[T] throughout the standard distribution. I'd like to take some
On 02/04/14 11:35 AM, Alex Crichton wrote:
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely remove many uses of
~[T] throughout
I compiled from source just yesterday, but everything's been going swimmingly!
I just have one comment on 0.10: It seems like println was removed
from the prelude. While I can totally appreciate that most people will
use println!, which is automatically use-able, it _is_ making my
'hello world'
On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik st...@steveklabnik.com wrote:
I compiled from source just yesterday, but everything's been going swimmingly!
I just have one comment on 0.10: It seems like println was removed
from the prelude. While I can totally appreciate that most people will
On 4/2/14 9:25 AM, Daniel Micay wrote:
On 02/04/14 11:35 AM, Alex Crichton wrote:
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely
On 02/04/14 02:28 PM, Patrick Walton wrote:
On 4/2/14 9:25 AM, Daniel Micay wrote:
On 02/04/14 11:35 AM, Alex Crichton wrote:
I've noticed recently that there seems to be a bit of confusion about
the fate
of ~[T] with an impending implementation of DST on the horizon. This
has been
On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay danielmi...@gmail.com wrote:
Without a size parameter to `free`, an allocator needs to track the size
of allocations manually. It increases the memory overhead, along with
adding bookkeeping overhead.
Not by very much... If a chunk's header is
Passing the size to free is currently in a C++14 proposal [1]. It's pretty
useful (makes free no slower, might make it faster) and in most code, the
size is available on free. I'm not sure it would should be mandatory, but
it's definitely useful.
[1]
On 02/04/14 03:18 PM, Clark Gaebel wrote:
Passing the size to free is currently in a C++14 proposal [1]. It's
pretty useful (makes free no slower, might make it faster) and in most
code, the size is available on free. I'm not sure it would should be
mandatory, but it's definitely useful.
On 02/04/14 03:13 PM, comex wrote:
On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay danielmi...@gmail.com wrote:
Without a size parameter to `free`, an allocator needs to track the size
of allocations manually. It increases the memory overhead, along with
adding bookkeeping overhead.
Not by
On 02/04/14 03:13 PM, comex wrote:
On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay danielmi...@gmail.com wrote:
But is that really worth hanging language features on, one
way or the other?
This also isn't the only optimization lost here. Zero-size allocations
will need to be clamped to one if
At the moment, Rust is completely broken in this regard. The following
expression evaluates to None:
Some(~())
Ouch, this is a disaster.
Is there a bug filed for this?
Anyway, I don't get your argument about size to free having anything to do with
fixing it (although I agree that size to
Clamping `malloc(0)` to `malloc(1)` means that allocations of 0-size
types will no longer be free, which is sad. It's very useful to be able
to have meet the requirement of having a trait object and avoid any
memory allocation if there's no state.
The sentinel does work, but adds a branch to
I've been worried about this decision too.
On 04/02/2014 10:34 AM, Steve Klabnik wrote:
I compiled from source just yesterday, but everything's been going swimmingly!
I just have one comment on 0.10: It seems like println was removed
from the prelude. While I can totally appreciate that most
On 02/04/2014 18:43, Corey Richardson wrote:
On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik st...@steveklabnik.com wrote:
I compiled from source just yesterday, but everything's been going swimmingly!
I just have one comment on 0.10: It seems like println was removed
from the prelude. While I
Personally, I'm strongly against doing using ~[] as return values from
library functions.
Imagine we were in world were we only had VecT and were adding a new
type OwnedSliceT that was (pointer, length) like ~[T]. For how many
library functions would we say it is sensible to throw away the
On 4/2/14 2:51 PM, Huon Wilson wrote:
Specifically, I don't see any concrete positives to doing this for
library functions other than lets keep using ~[T] and ~[T] [T]
having the same in-memory representation (covered below).
Under any scheme I can think of, there are negatives:
1. without
On 03/04/14 08:54, Patrick Walton wrote:
On 4/2/14 2:51 PM, Huon Wilson wrote:
Specifically, I don't see any concrete positives to doing this for
library functions other than lets keep using ~[T] and ~[T] [T]
having the same in-memory representation (covered below).
Under any scheme I can
On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote:
I have no sane proposal to fix this beyond passing a size to free.
I don't believe there is a problem with just not using null to
represent such pointers (for example, 1 would suffice). This does
impose some additional burdens on
On 02/04/14 07:22 PM, Niko Matsakis wrote:
On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote:
I have no sane proposal to fix this beyond passing a size to free.
I don't believe there is a problem with just not using null to
represent such pointers (for example, 1 would suffice).
And just in case there is a confusion (as I have noticed others to
have), it might help to see a specific example comparing static
dispatch with dynamic.
// This is a single function for all types implementing the LCD Trait.
fn foo(x : LCD) { // x's type is LCD rather than the actual type of
the
On Apr 2, 2014, at 8:35 AM, Alex Crichton a...@crichton.co wrote:
As a concrete example, I'll take the read_to_end() method on io's Reader
trait.
This type must use a VecT internally to read data into the vector, but it
will
return a ~[T] because the contents are conceptually frozen after
On Apr 2, 2014, at 3:01 PM, Huon Wilson dbau...@gmail.com wrote:
On 03/04/14 08:54, Patrick Walton wrote:
What about strings? Should we be using `StrBuf` as well?
I don't see why not. The same arguments apply.
I agree. I was actually quite surprised to see that the type was named StrBuf,
On Apr 2, 2014, at 2:08 PM, Simon Sapin simon.sa...@exyr.org wrote:
On 02/04/2014 18:43, Corey Richardson wrote:
On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik st...@steveklabnik.com wrote:
I compiled from source just yesterday, but everything's been going
swimmingly!
I just have one
Perhaps we should have `print` and `println` back in the prelude and
call these `printf!` and `printfln!`. I think it would be a lot clearer,
as people always ask how these are different from `print` and `println`.
signature.asc
Description: OpenPGP digital signature
On Apr 2, 2014, at 10:14 PM, Daniel Micay danielmi...@gmail.com wrote:
Perhaps we should have `print` and `println` back in the prelude and
call these `printf!` and `printfln!`. I think it would be a lot clearer,
as people always ask how these are different from `print` and `println`.
I would
28 matches
Mail list logo
