The name itself is standard, like it is the default settings...
Le 12 nov. 2013 02:35, Steven Fackler sfack...@gmail.com a écrit :
base64.rs:
let s = [52, 53, 54].to_base64(STANDARD);
= why adding the standard argument? One will ALWAYS want the
STANDARD method of creating the base64
The Rust way to do that would be to have an array of objects that all
implement the needed trait. But that would mean that access to the data
members would be a virtual function call, while access to the data
members of the new kind of traits you described would be cheap.
I think that introducing
On 11/12/13 5:17 PM, Oren Ben-Kiki wrote:
I think that introducing two kinds of traits would have non-obvious
implications on the type system
Example?
in addition to saddling us with all the
pains of a single-inheritance types hierarchy system.
I don't think so. In any case.
Also,
On 11/11/2013 09:46 PM, Corey Richardson wrote:
I don't think Rust can succeed as a language if it massively differs,
visually, from the language it intends to offset (C++).
I don't think Rust can succeed as a language if it massively resembles
the language it intends to offset (C++).
Denis
Does anyone have empirical data (or even anecdotes) about whether or not
C++ hackers find Rust's syntax appealing? :-)
On Tue, Nov 12, 2013 at 10:53 AM, spir denis.s...@gmail.com wrote:
On 11/11/2013 09:46 PM, Corey Richardson wrote:
I don't think Rust can succeed as a language if it
My opinion is that clear semantics and good documentation is much more
important than familiar syntax. Besides, it's not too closely C++ syntax; for
example `let x : T = v` is much closer to Scala's `val x : T = v` than C++'s
`T x = v`. (This is a good choice, as anyone who know's why C++ has a
On 11/11/2013 09:16 PM, Oren Ben-Kiki wrote:
At any rate, I'm not claiming this is necessarily the best approach for
Rust; I'm just wondering, what is the proposed way to address this use
case? None of the manual approaches seems very appealing (unless there's a
better one I missed).
My
More concretely, a good ide with completion, the right snippets and
contextual help is very helpful for learning new language.
I thing this could be a good idea to have an official set of snippets,
typical every day codes, that can be used to create a common contextual
helps for editors (vim,
Hello Rust people,
A data structure holds (unpointed) cells in an array. Then, a number of linked
lists part of the data structure link to those same cells. What is the right
Rust way to do that? I cannot have the language accept the instruction
establishing a link, whatever kind of pointer I
Hi,
I was thinking about a small enhancement for OptionS objects where S: Str
that would add a utility method for returning a slice option.
There is some code in rust-pcre,
https://github.com/cadencemarseille/rust-pcre/blob/d833054/src/pcre/mod.rs#L137,
that I think illustrates what I am trying
I have been struggling with variants of this for a while and there's no
best solution.
First, if the array holds values (as opposed to pointers to values), then
pretty much your only option is to replace your pointers with indices to
the array. You'd need access to the container to access the
This will work for your pattern match without cloning:
match self.opt_err {
None = format!(compilation failed at offset {:u}, self.erroffset
as uint),
Some(ref s) = format!(compilation failed at offset {:u}: {:s},
self.erroffset as uint, *s)
}
It
On 11/12/13 9:51 PM, Oren Ben-Kiki wrote:
If sending the whole thing is an issue, you are pretty much forced to
use ArcT (and forget about reference cycles). And, of course, each of
these (Rc, @, Arc) has a different name if you want mutation (RcMut,
@mut, ArcRW).
I think having to choose
Yes, you lose the ability to deallocate individual nodes. Pretty hard to
express in a type system. Still I wish I could at least have the compiler
help me to ensure my unsafe pointers never escape the lifetime of the
container; right now I must trust the programmer (and in my case, the
container
Hello,
The ref manual speaks of copying pointers
[http://static.rust-lang.org/doc/0.8/rust.html#pointer-types]:
Managed pointers (@)
These point to managed heap allocations (or boxes) in the task-local,
managed heap. Managed pointers are written @content, for example @int means a
Thank you, Micah. Your suggestion and Léo Testard's suggestion using
s.as_slice() (emailed off-list) work well.
Cadence
On Tue, Nov 12, 2013 at 8:01 AM, Micah Chalmer mi...@micahchalmer.netwrote:
This will work for your pattern match without cloning:
match self.opt_err {
Hello
Sorry for the mail being sent off-list. Here's what I suggested in case it
helps somebody else:
match opt_err {
None = format!(compilation failed at offset {:u}, 0u),
Some(ref s) = format!(compilation failed at offset {:u}: {:s}, 0u,
s.as_slice())
};
Le 12 nov.
PS: What would be, in fact, the rusty way for a simplissim linked list. I use
Option~Cell for now, to have something clean (None) to end the list, since
Rust looks rather functional. But as always with Option this way quite obscures
and complicates the code (Some() expressions, match
For linked lists with no cycles, why not use OptionRcT (or RcMut)?
On Tue, Nov 12, 2013 at 4:06 PM, spir denis.s...@gmail.com wrote:
PS: What would be, in fact, the rusty way for a simplissim linked list. I
use Option~Cell for now, to have something clean (None) to end the list,
since Rust
#[feature(managed_boxes)];
#[deriving(Clone)]
struct Foo;
impl Drop for Foo {
fn drop(mut self) { }
}
fn main() {
let x = ~Foo;
let y = @Foo;
let _z = Foo;
let z = _z;
// needs a clone since just `a = x` would be a move
let a: ~Foo = x.clone();
// just copies
Curious if Rust has a way to get the Color of a Screen Pixel yet ?
http://rosettacode.org/wiki/Color_of_a_screen_pixel
--
-Thad
+ThadGuidry https://www.google.com/+ThadGuidry
Thad on LinkedIn http://www.linkedin.com/in/thadguidry/
___
Rust-dev mailing
With the xlib bindings it'd look a lot like the C version.
On Tue, Nov 12, 2013 at 12:11 PM, Thad Guidry thadgui...@gmail.com wrote:
Curious if Rust has a way to get the Color of a Screen Pixel yet ?
http://rosettacode.org/wiki/Color_of_a_screen_pixel
--
-Thad
+ThadGuidry
Thad on LinkedIn
On Nov 12, 2013, at 12:15 PM, Tiffany Bennett tiff...@stormbit.net wrote:
[.. a bunch of flamebait ..]
Sorry, not gonna bite.
I think there was one reply-worthy comment buried in there, perhaps a tacit
request for remove-worthy syntax examples?
I can point out syntax that I don't like, but I
Hi folks --
I already requested that this thread end, and from here on I'm going
to place anyone who replies to this thread further (with the same
subject line or quoting anything from the same thread) on temporary
moderation. For any specific discussion about Rust that originates
from this
On Tue, Nov 12, 2013 at 12:37 PM, Greg g...@kinostudios.com wrote:
On Nov 12, 2013, at 12:15 PM, Tiffany Bennett tiff...@stormbit.net
wrote:
[.. a bunch of flamebait ..]
Sorry, not gonna bite.
I think there was one reply-worthy comment buried in there, perhaps a
tacit request for
Sorry, I did go a bit overboard
On Tue, Nov 12, 2013 at 12:48 PM, Tim Chevalier catamorph...@gmail.comwrote:
Hey Tiffany --
Just wanted to let you know that I thought this was a totally
appropriate email on your part :-) Normally I would warn about the
code of conduct, but tbh, in this case
On Nov 11, 2013, at 11:43 PM, Patrick Walton pcwal...@mozilla.com wrote:
We considered Go's anonymous fields but rejected them because they don't
support virtual methods at the same time as field embedding.
I don’t follow. Why do Go’s anonymous fields not support virtual methods at the
same
Right now, Rust does not support catching task failure from within a task, it
only supports preventing task failure from cascading into other tasks. My
understanding is that this limitation is done because of safety; if a task
unwinds through a few frames of code, and then stops unwinding, data
Could the compiler figure out if a static item is not used and then elide it
altogether. Or does it do this already?
I can use the following idiom in C++ (can't do it in Rust though) to have the
compiler elide static data (large lookup tables in library code for example) if
the end-user
On Tue, Nov 12, 2013 at 2:17 PM, Tommi rusty.ga...@icloud.com wrote:
Could the compiler figure out if a static item is not used and then elide it
altogether. Or does it do this already?
If it's a `pub static`, and you're compiling a library, it cannot be
removed. But if it's just static and
Is it possible for data low in the stack to propagate upwards through
the stack before function return? It seems like if this were to be an
issue, you would need to move into something parent gives you, at
which point you no longer have ownership and unwinding won't destroy
it.
It seems like the
You're correct about the safeness of catching failure at a task
boundary. Rust's invariants about spawning a task involve knowing a
fair bit about what's allowable to share between a task boundary, and
that allows us to reason about the failure unwinding to the task
boundary being a safe operation
On Tue, Nov 12, 2013 at 2:35 PM, Alex Crichton a...@crichton.co wrote:
You're correct about the safeness of catching failure at a task
boundary. Rust's invariants about spawning a task involve knowing a
fair bit about what's allowable to share between a task boundary, and
that allows us to
I'd suggest extra::list, but it looks a little dated.
On Tue, Nov 12, 2013 at 6:21 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
For linked lists with no cycles, why not use OptionRcT (or RcMut)?
On Tue, Nov 12, 2013 at 4:06 PM, spir denis.s...@gmail.com wrote:
PS: What would be, in fact,
The list is no longer on moderation. Posts from subscribers should go
through to the list without moderator intervention now.
Sorry for any inconvenience.
Cheers,
Tim
On Tue, Nov 12, 2013 at 10:10 AM, Tim Chevalier catamorph...@gmail.com wrote:
I've placed the list on full moderation for now,
I guess I was being too vague when I said “C exceptions”, because you’re right,
that’s not actually a specific thing. More concretely, I was thinking of either
C++ exceptions, or Obj-C exceptions.
One situation I was thinking of would be a rust library that exposes `extern
“C”` functions.
Previously I replied incorrectly to the mail, so I'm replying to it anew just
to show how the discussion went from here on. Still learning mailing lists,
sorry.
These are the missing posts:
On 2013-11-12, at 21:42, Corey Richardson co...@octayn.net wrote:
On Tue, Nov 12, 2013 at 2:39 PM,
On Tue, Nov 12, 2013 at 9:42 PM, Kevin Ballard ke...@sb.org wrote:
I guess I was being too vague when I said “C exceptions”, because you’re
right, that’s not actually a specific thing. More concretely, I was
thinking of either C++ exceptions, or Obj-C exceptions.
One situation I was thinking
On Nov 12, 2013, at 1:22 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/13/13 3:57 AM, Kevin Ballard wrote:
On Nov 11, 2013, at 11:43 PM, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
We considered Go's anonymous fields but rejected them because they
don't
On 11/13/13 12:06 PM, Daniel Micay wrote:
It's completely possible to write safe bindings to a C++ library. The
process involves wrapping the whole thing with `extern C` functions
using catch blocks for any function possibly throwing an exception. Keep
in mind that libraries already have to do
On 11/13/13 12:18 PM, Kevin Ballard wrote:
The only penalty this approach has (that comes to mind) over the
single-inheritance model is that, because of the loss of the prefix
property, any field access on the trait object itself will require
looking up the field offset in the virtual table. But
On Nov 12, 2013, at 9:01 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 11/13/13 12:18 PM, Kevin Ballard wrote:
The only penalty this approach has (that comes to mind) over the
single-inheritance model is that, because of the loss of the prefix
property, any field access on the trait
On Nov 12, 2013, at 10:26 PM, Kevin Ballard ke...@sb.org wrote:
And even that restriction could be lifted if ~Trait objects could be
represented using an array of pointers (one to each inherited struct), e.g.
([*A,*B,*C],*vtable) instead of just (*A,*vtable), though I suspect this is
not
It seems the argument on single-inheritance hinges on the following use
case:
struct Foo { foo: int }
struct Bar : Foo { bar: bar }
fn main() {
let myFoos = [Foo{ foo: 1 } as ~Foo, Bar{ foo: Foo{foo: 1}, bar: 2} as
~Foo];
for myFoo in myFoos.iter() {
myFoo.foo; // Fixed offset
44 matches
Mail list logo
