To expand upon what Corey was saying, `box` is basically a huge
special-cased hack right now. I'm surprised that a mention of `box(GC)` is
even included in the tutorial. Someone tell Steve to rip that out. :P
We'll be clarfiying how best to use `box` before 1.0. In the meantime, just
don't use GC.
> Are you starting to support these releases with bug-eliminations?
AFAIK there is no intention to start issuing bugfix releases at this time.
The reason for the extra number at the end is for stricter adherence to
Semantic Versioning, which requires a bugfix number.
On Wed, Jul 2, 2014 at 5:50
Well done! 1.0 draws closer every day. I'm giddy with anticipation.
On Wed, Jul 2, 2014 at 2:07 PM, Alex Crichton wrote:
> Mozilla and the Rust community are pleased to announce version 0.11.0 of
> the Rust compiler and tools. Rust is a systems programming language with a
> focus on safety, per
If the vast majority of types take only a single type parameter, then it
could potentially be worth considering using a unary sigil. (I think D does
something like this.)
Choosing the tilde as the arbitrary symbol here, your example would look
like Arc~Exclusive~Vec~Box~Buffer~T. If you have multi
> the fact is that everyone is an optimist when it comes to integer
overflow bugs. People just do not think they're going to get bitten.
I agree, and I don't think anyone else here is going to try to argue that
this doesn't cause real bugs. As so often seems to be the case, language
design amount
> I feel like Rust might be missing out on the free lunch I expect Swift to
provide
I think that it may be unfounded to expect Swift to spur drastic
improvements to any aspect of LLVM. Apple is already the biggest benefactor
of LLVM, which powers the C compiler their OS is built with, the
Objectiv
> Ada's approach to integer overflows is substantially similar to AIR
Isn't Ada's response to overflow implementation-defined?
On Mon, Jun 23, 2014 at 11:37 AM, John Regehr wrote:
> I would think that something simple like
>>
>>let mut sum = 0;
>>for x in some_int_array.iter() {
>>
I apologize for being hostile. As Florian has noted, we're just arguing
about the default behavior here. It is my opinion that checked behavior by
default will make Rust unsuitable for filling C++'s niche, and send the
message that we are not serious about performance.
On Sun, Jun 22, 2014 at 12:
un 22, 2014 at 2:02 AM, Daniel Micay
> wrote:
>
>> On 21/06/14 07:55 PM, Benjamin Striegel wrote:
>> >> No one will use Rust if it's slow. If it uses checked arithmetic, it
>> >> will be slow. There's nothing subjective about that.
>> >
>>
". Just
> because that's *your* usecase for it doesn't mean you should force it on
> others.
>
>
> On Sun, Jun 22, 2014 at 10:32 AM, Benjamin Striegel <
> ben.strie...@gmail.com> wrote:
>
>> > Even though Rust is a performance conscious language
> Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust code
should not require absolute speed
This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge c
> No one will use Rust if it's slow. If it uses checked arithmetic, it
> will be slow. There's nothing subjective about that.
This is the only argument that matters.
If we are slower than C++, Rust will not replace C++ and will have failed
at its goal of making the world a safer place. The world
> A user won't care if Arc and Rc are built-in or not.
They will definitely care, once they attempt to write their own pointer
types and find that they're second-class citizens compared to the types
that have been blessed by the compiler. There's little point in having a
powerful and extensible la
all over the place when using` Rc`. That, to me, seems very important (in
>> making smart pointers first class citizens of Rust, without this, I would
>> rather go back to having @-pointers). The trouble is, I see incrementing a
>> ref count as the upper bound on the work that
the upper bound on the work that should be done in a copy
> constructor and I see no way to enforce that.
>
> So, I guess +1 to spirit of the OP, but no solid proposal for how to do it.
>
>
> On Sat, Jun 21, 2014 at 8:00 AM, Benjamin Striegel > wrote:
>
>> I'm not
I'm not a fan of the idea of blessing certain types with a compiler-defined
whitelist. And if the choice is then between ugly code and copy
constructors, I'll take ugly code over surprising code.
On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton
wrote:
> On 6/20/14 12:07 PM, Paulo Sérgio Almeida
I'm actually very pleased that floating point literals are entirely
separate from integer literals, but I can't quite explain why. A matter of
taste, I suppose. Perhaps it stems from symmetry with the fact that I
wouldn't want `let x: int = 1.0;` to be valid.
On Thu, Jun 19, 2014 at 7:02 PM, Matt
This is great! But how are we testing this? Do we have an iOS buildbot? Or
is it liable to break at any moment?
On Mon, Jun 16, 2014 at 2:04 PM, Alex Crichton wrote:
> Nice job Valerii! This is all thanks to the awesome work you've been
> doing wrangling compiler-rt and the standard libraries.
> The manner in which the expression accomplishes this task is an
implementation detail.
You're welcome to draft a proposal if you think that you have an idea to
make this possible. Though all of the solutions that I can envision require
abandoning the idea of operators-as-traits and introducing a
This does raise a good question though: post-1.0, will we continue the
current procedure of snapshotting whenever we feel like it, or will we
restrict snapshots to stable releases, as Go plans to do?
https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true
This is quite an undertaking. Thanks for taking the initiative!
On Sun, Jun 8, 2014 at 4:10 AM, Dietrich Epp wrote:
> Unless there’s a good objection I’m taking ownership of the datetime
> library, as luisbg’s efforts seem to be abandoned. I’ve read the wiki, the
> last mailing list discussion
The manual also says that `as` somehow has a lower precedence than `*` and
yet a higher precedence than `+`, which would be hilarious madness. Don't
trust the manual.
On Fri, May 30, 2014 at 11:02 AM, Tommi wrote:
> The manual says that the precedence of `as` operator is lower than that of
> th
What you're overlooking is that patterns are used for more than just
`match` expressions. They can also be used in both assignment statements
and in function/closure signatures. For example, note that `x` and `y` are
the same type in the following program:
fn main() {
let ref x = 3;
Oh and while we're belligerently bikeshedding, we should rename `to_str` to
`to_string` once we rename `StrBuf` to `String`. :)
On Wed, May 28, 2014 at 9:00 PM, Benjamin Striegel
wrote:
> > but people will still end up calling the
>
> *exact same method*
> ...Except when th
> but people will still end up calling the
*exact same method*
...Except when they actually intended to call any other method of
determining the length of a string, but were stymied by poor naming and
inadequate understanding. But if your argument is "people will only call
the method that tells th
On May 28, 2014, at 1:26 PM, Benjamin Striegel
> wrote:
>
> > Unicode is not a simple concept. UTF-8 on the other hand is a pretty
> simple concept.
>
> I don't think we can fully divorce these two ideas. Understanding UTF-8
> still implies understanding the difference
t. Dedicating
ourselves to Unicode support does us no good if the remainder of our API
encourages the depressingly-typical ASCII-ism that pervades nearly every
other language.
On Wed, May 28, 2014 at 3:48 PM, Kevin Ballard wrote:
> On May 28, 2014, at 11:55 AM, Benjamin Striegel
> wr
x27;t already
> memorized this difference.
>
> Today we only need to teach the simple concept that strings are utf-8
> encoded, and the corresponding notion that all of the accessor methods on
> strings (including indexing using []) use code units unless they specify
> o
length is
> not O(1) and not appropriate for use with most string-manipulation
> functions).
>
> Since Rust strings are UTF-8 encoded text, it makes sense for .len() to be
> the number of UTF-8 code units. Which happens to be the number of bytes.
>
> -Kevin
>
> On May 28, 2014, at 7:
I think that the naming of `len` here is dangerously misleading. Naive
ASCII-users will be free to assume that this is counting codepoints rather
than bytes. I'd prefer the name `byte_len` in order to make the behavior
here explicit.
On Wed, May 28, 2014 at 5:55 AM, Simon Sapin wrote:
> On 28/0
since I
have seen little discussion regarding it.
On Tue, May 27, 2014 at 10:17 PM, Kevin Ballard wrote:
> On May 27, 2014, at 1:55 PM, Benjamin Striegel
> wrote:
>
> What I was specifically curious about is why you seem to be against the
> usage of the `Str` trait as a bound
What I was specifically curious about is why you seem to be against the
usage of the `Str` trait as a bound on the argument to the `captures`
method.
On Tue, May 27, 2014 at 1:01 PM, Kevin Ballard wrote:
> On May 27, 2014, at 6:05 AM, Benjamin Striegel
> wrote:
>
> > The us
ad very little discussion so far.
>
> My suggestion is to wait until we have DST, then file an RFC suggesting
> the autoderef behavior for function arguments (and suggesting Deref on
> String if we haven't already done that).
>
> -Kevin
>
> On May 26, 2014, at 12:10 PM
I'm not familiar with the getopts module, but on the surface that behavior
sounds wrong to me.
As for the verbosity of the repeated `to_owned` calls, this sounds like the
perfect application for macros:
#![feature(macro_rules)]
macro_rules! owned(
($($e:expr),*) => ([$($e.to_owne
I don't think any of these will be necessary.
We already have a trait called `Str` (which is a bad name, btw) in the
std::str module. This trait has exactly one method: `as_slice`. This trait
is already implemented on both `&str` and `StrBuf` (the former in std::str,
the latter in std::strbuf). Al
On Fri, May 23, 2014 at 12:12 AM, Patrick Walton wrote:
> You can use "extern "Rust" fn" (or ||:'static) to achieve something like
> C++03 member function pointers without the lifetimes. Attacking Rust
> without asking first how to do this is unappreciated.
>
I think that characterizing this as
Welcome!
The easiest way to install the compiler will be to download the binaries
here:
http://www.rust-lang.org/install.html .
Prefer the "Nightly" binaries and not the 0.10 binaries. Unzip the download
and run the "install.sh" script inside.
If you're using Linux, you can do the above ste
Originally, ancient versions of Rust allowed you to nest block comments.
Then we decided this was too surprising and too hard to parse, so we took
it out. Then we decided that this was too useful to exclude so we added it
back in, but apparently this time we forgot to update the manual. Just
anothe
> We're just being overly restrictive for legacy reasons.
This same sentiment appears in https://github.com/rust-lang/rfcs/pull/48 .
How many more rules are we imposing that exist only for "legacy reasons"?
Is addressing them all a priority for 1.0?
On Wed, Apr 23, 2014 at 10:09 PM, Niko Matsak
Welcome Aaron! And "LVars" sounds familiar... was that something that
Lindsey Kuper was working on?
On Mon, Apr 21, 2014 at 5:18 PM, Alex Crichton wrote:
> Welcome Aaron! I'm so excited to have you with us!
>
> On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson
> wrote:
> > Hey there, Rusticators
In terms of making hello world nice in 0.10, I prefer to simply put
something else in the format string in order to clarify what the first
argument is there for:
fn main() {
let x = "world";
println!("Hello, {:s}!", x);
}
Also remember that saying `println!("Hello, world!"
gather
> sometime soon and talk about Rust!
>
> Sincerely,
> ~~Davis Silverman
> ~Sinistersnare
>
>
>
> On Fri, Mar 14, 2014 at 8:07 PM, Benjamin Striegel > wrote:
>
>> Not NYC, but I'm in the DC area until next week if anyone wants to hang
>>
> macros are needed for most uses of print functions
since you generally want variable number of arguments
In addition to that a plain function wouldn't be able to verify a format
string at compile-time.
On Fri, Mar 14, 2014 at 5:55 PM, Jack Moffitt wrote:
> A suffix ! means that you are using
Not NYC, but I'm in the DC area until next week if anyone wants to hang
out. :)
Maybe we need some kind of general geographic Rust meet-up service...
On Fri, Mar 14, 2014 at 7:40 PM, Jason Fager wrote:
> I'd be in.
>
>
> On Thursday, March 13, 2014, Clark Gaebel wrote:
>
>> Hey I'm in NYC and
Is it correct for me to assume that, even if accepted, virtual things will
be behind a feature flag for 1.0? If so, then I think that will be enough
friction to cause library authors to favor traits instead, especially if
users of virtual-using-libraries would have to turn on the feature flag as
we
> Should the mailing list be involved in this process, as a way to get more
people discussing RFCs?
I'm using Github's "watch" feature on the RFC repo so that I am
automatically emailed whenever a new PR pops up or a discussion occurs.
These emails then get filtered to a "Rust RFCs" folder for eas
Rather than discuss this here, let's start dogfooding:
https://github.com/rust-lang/rfcs/pull/2
On Wed, Mar 12, 2014 at 3:54 AM, Flaper87 wrote:
>
>
>
> 2014-03-12 2:11 GMT+01:00 Brian Anderson :
>
> [snip]
>
>
>> -
>>
>> Many changes, including bug fixes and documentation improvements can
I'm seeing unnecessarily hostile and dismissive comments from several
participants here. If you can't be civil, then ignore the thread and move
on.
On Tue, Mar 4, 2014 at 11:40 PM, Liigo Zhuang wrote:
> If I select Rust as my main language, I don't think I have any reason to
> write new code in
Having read this week's meeting notes on this topic:
> we'll get bors to warn people about not putting the issue number in
commit messages
Can anyone elaborate on what this will entail? By "commit message" do you
mean the honest-to-god git commit message, or the Github PR message, or
both? What f
Though if you don't record it, you can offer to give the presentation
remotely at the monthly Bay Area Rust Meetup. :)
On Fri, Feb 14, 2014 at 12:18 PM, Ian Daniher wrote:
> I can make sure it's recorded & put on youtube.
>
>
> On Fri, Feb 14, 2014 at 12:01 PM, Jack Moffitt wrote:
>
>> This sou
> there is a plan for llvm before 1.0.
What does this refer to? Last I checked we were certain to still be using a
custom LLVM as of 1.0.
On Tue, Feb 11, 2014 at 1:18 PM, Luca BRUNO wrote:
> Tom Lee wrote:
>
> > I've cced Luca Bruno in since I think he's been keeping a closer eye
> > on the d
> We can also attempt to package Rust with various of the most common
package managers: homebrew, macports, dpkg, rpm.
It would be great to have these for the point releases, but do all of these
allow for nightly builds?
On Thu, Feb 6, 2014 at 7:35 PM, Brian Anderson wrote:
> Hey.
>
> One of my
Awesome! What a cool find. As well, this lends credence to my previously
unfounded suspicion that we were one of the most prolific users of Github's
issue tracking system. This should give us some leverage the next time that
we feel the need to complain about the UI. :P
On Wed, Feb 5, 2014 at 7:2
Congratulations!
On Mon, Feb 3, 2014 at 10:11 PM, Tim Kuehn wrote:
> Fantastic! Good luck, Nick!
>
>
> On Mon, Feb 3, 2014 at 6:51 PM, Alex Crichton wrote:
>
>> Welcome Nick!
>>
>> I can't wait to see that 1.0 issue count go down!
>>
>> On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson
>> wrote:
It might be good to revisit proc syntax, but I don't think that it's yet
time for that. There's a nebulous plan in the works involving
reimplementing closures as traits (or... something?) and how that shakes
out would likely impact the syntax that we want to provide.
On Mon, Feb 3, 2014 at 11:26
After sleeping on it I'm not convinced that this would be a net improvement
over our current situation. With a few caveats I'm really rather happy with
the syntax as it is.
On Sun, Feb 2, 2014 at 8:55 AM, Jason Fager wrote:
> I'm not a huge fan of this proposal. It makes declarations longer, a
ll, because you expect a loop
> there, not a generic type bound. How about 'any':
>
> any fn foo (t: T, u: U) -> ...
>
> ?
>
>
> On Sat, Feb 1, 2014 at 11:06 PM, Benjamin Striegel > wrote:
>
>> Another point in favor of this plan is that i
:
for {
fn foo(t: T, u: U) -> (T, U) {
...but that's even *more* boilerplate!
On Sat, Feb 1, 2014 at 5:59 PM, Benjamin Striegel wrote:
> > Yes, and I don't have a solution for that.
>
> Well, it's not like we don't already stumble here a bit, wh
> On Sat, Feb 1, 2014 at 5:55 PM, Benjamin Striegel
> wrote:
> > First of all, why a new keyword? Reusing `for` here would be totally
> > unambiguous. :P And also save us from creating the precedent of
> multi-word
> > keywords.
> >
>
> I'd be equa
First of all, why a new keyword? Reusing `for` here would be totally
unambiguous. :P And also save us from creating the precedent of multi-word
keywords.
Secondly, currently Rust has a philosophy of use-follows-declaration (i.e.
the syntax for using something mirrors the syntax for declaring it).
> Is using dummy struct fields for specifying custom type bounds on the
struct itself really the best we can do in a brand-new language?
I as well wonder if there's a better way to do this (but I'm note the one
to ask).
> On a slightly different note, is there a strong reason for having to name
l
> https://github.com/mozilla/rust/issues/2643
I came here to post that link, you beat me to it. :)
Highly, vehemently, frothing-at-the-mouthly against adding `var` as sugar
for `let mut`. You can see from reading that issue that I too was once a
fan of getting rid of `let mut`, but after using Ru
not be for them.
On Fri, Jan 24, 2014 at 9:45 AM, Lee Braiden wrote:
> On 24/01/14 13:34, Benjamin Striegel wrote:
>
>> Anyway, if we've devolving into bikeshedding then it might be time to
>> abandon this thread. Usability isn't something that can be crowdsourced.
&
ter naming of port and chan
> * Channel should have a ChannelTrait implemention, with send() and
> receive(), and should be created by Channel::new()
>
> But from what Benjamin says below, it seems like the latter isn't
> necessary.
>
>
> On Jan 23, 2014 7:29 PM, "
point is that
>> Channel::new() would generally be expected to return a struct, and not a
>> tuple.
>>
>> On Jan 23, 2014 7:29 PM, "Benjamin Striegel" > <mailto:ben.strie...@gmail.com>> wrote:
>>
>> This all seems a bit silly. A channel *is*,
This all seems a bit silly. A channel *is*, conceptually, a tuple of a
sender and a receiver. If I call Chan::new(), that's what I expect to get.
And Chan::open() doesn't map to anything that's as intuitive.
Is naming really all that's left to argue about? How does everyone feel
about the semantic
Congrats everyone! Here's to 0.10. :)
On Thu, Jan 9, 2014 at 4:04 PM, Brian Anderson wrote:
> Mozilla and the Rust community are pleased to announce version 0.9 of the
> Rust compiler and tools. Rust is a systems programming language with a
> focus on safety, performance and concurrency.
>
> Th
I'm not sure if this is generally feasible! If memory-unsafe C/C++ code
could be automatically and mechanically converted to memory-safe Rust code,
then that would imply the existence of static analysis tools for C/C++ code
that could themselves guarantee memory safety without requiring Rust at all
Every time that we've added magic, we've lived to regret it and ultimately
revert it. If there exists only a single lesson of the past few years of
language evolution, let it be this.
Furthermore, any discussions of monads and/or HKT are pie-in-the-sky at
this point. Our complexity budget is stret
on, Dec 23, 2013 at 3:40 PM, Simon Sapin wrote:
> On 23/12/2013 20:55, Benjamin Striegel wrote:
>
>> I too think it would be a big mistake to allow let patterns to be
>> refutable, when we've already tried and rejected allowing the same in
>> match statements (an
I too think it would be a big mistake to allow let patterns to be
refutable, when we've already tried and rejected allowing the same in match
statements (ancient Rust history quiz: who else remembers `match check`?).
On Mon, Dec 23, 2013 at 2:44 PM, Gábor Lehel wrote:
> That seems like a nice c
> the OCaml compiler complains with a warning if you use a refutable
pattern in `let`.
And what does OCaml do at runtime if the pattern is refuted?
On Mon, Dec 23, 2013 at 12:23 PM, Patrick Walton wrote:
> On 12/23/13 4:12 AM, Gábor Lehel wrote:
>
>> I don't like either that (a) the possible fa
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:
http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html
I know that Rust doesn't have quite the same task communication primitives
as
> 3. *Using inheritance for collection mutability is bad.* Rust doesn't do
it.
Is this an argument against generalizing over mutability at all (as I
believe has been proposed in the past)?
On Wed, Dec 4, 2013 at 10:53 PM, Patrick Walton wrote:
> On 12/4/13 5:07 PM, Ziad Hatahet wrote:
>
>> To b
Hooray, welcome to our new contributors! :) And thanks to our mentors and
coordinators as well!
On Wed, Dec 4, 2013 at 11:18 AM, Tim Chevalier wrote:
> Hello,
>
> I'm pleased to announce that the winter/spring Rust and Servo interns
> through the GNOME Outreach Program for Women (
> https://wiki
Apparently even Brian doesn't know how to do this, so I figured I'd share
this tip.
The rust-dev mailing list is archived here:
http://thread.gmane.org/gmane.comp.lang.rust.devel/
Use the search box at the bottom to search through the mailing list's
archives since the beginning of time.
When yo
This is very cool! But, I agree with Daniel. If there's any way that we can
reduce the duplication of effort, we should. This is especially true given
that we don't have anything close to an accurate written specification to
help keep two implementations in sync.
On Tue, Dec 3, 2013 at 12:54 PM,
If `expr @ place` suffices then you'd think that re-using `in` keyword as
per `expr in place` would also work, but I believe we rejected that for
technical reasons in past discussions. And if those technical reasons no
longer apply, I'd like to motion that `in` looks way better than `@` there.
:)
> The idea of an online user forum would be that people with an interest in
Rust can read in the user forum which is easier to peruse than some mail
list archive. Asking and getting answers seems to work more fluently.
I agree with the principle, but we have yet to identify what users would
actual
I'm not sure that discussion forums are the best alternative to the typical
"foo-users" mailing list. Topics are generally less about discussion and
more about getting a quick answer to a problem; IRC is okay for this at the
moment, but once Rust stabilizes I'd much prefer just using StackOverflow
Eh, I'm as fine with `box` as I am with `new`. Does seem a bit like jargon,
though. Though maybe it will herald a return to the days when we really
played up the "shipping container" flavor. Crates and cargo, anyone? :)
On Sun, Dec 1, 2013 at 12:42 AM, Patrick Walton wrote:
> On 11/30/13 6:49 PM
> The other suggestion that's been floated that satisfies all of these
constraints is `alloc`, and honestly, if `new` is that unpopular maybe we
should just switch to that.
I much prefer `new` to `alloc`. It *is* a shame that `foo::new()` has to
change, but `alloc` is much grosser than `init`. And
It's okay, it's our own fault for not having yet written a document
entitled "Things That Absolutely Will Not Change And That We Are Tired Of
Discussing." :P
On Sat, Nov 30, 2013 at 4:34 PM, Gaetan wrote:
> Sorry for this offtopic subject..
> Le 30 nov. 2013 20:
> (I forget the name, sadly)
This is usually referred to as Tennet's Correspondence Principle:
http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html
...though it is sometimes debated whether or not the modern interpretation
of this principle is actually what Tennet intend
Currently our `for` loops are implemented strangely. In essence, right now
a `for` loop is just syntax sugar that gets expanded during the parsing
stage. This was easy to implement, but it means that our error messages
around `for` loops are strange and it limits our ability to do more
intelligent
> Is is possible to get rid of this returnless return?
> I mean, it is really hard yo read, why not enforcing the use of return
statement, always?
This isn't the point of this thread, and also I don't think anybody is
willing to revisit this issue. Consider that ship as having sailed beyond
the ho
> If "do" is still causing confusion, I'd rather just remove it entirely.
I rather like `do`. I agree that if it's confusing it should be considered
for removal, but IMO the confusion here stems from familiarity with the
prior, obsolete semantics rather than any inherent problem with the
construct
> LLVM does, yes, but I'd still be interested in a perf comparison of us
> not translating the dead code compared to LLVM stripping it later.
> Clang does this, for example.
But if the idea here is also to provide a dead-code warning during
compilation, is it necessary to add this feature to the f
> This is an even sillier idea, but then what about keeping `loop` and
dropping `while`?
I'm not sure this is possible to disambiguate in the grammar. You'd have to
be able to tell the difference between the infinite form:
loop
...and the conditional form:
loop
...while keeping in m
Obligatory link to Niko's blog post on this topic:
http://smallcultfollowing.com/babysteps/blog/2013/11/20/parameter-coercion-in-rust/
I do agree that explicitness is nice, but too much noise will harm
readability just as much as magic does.
It also doesn't help that the `&*` operator is a bit mi
If autoref still happens on methods, does this mean that you'd be able to
get around the need to do:
sort(&mut *foo);
...by turning it into a method?
foo.sort();
On Tue, Nov 19, 2013 at 6:10 PM, Kevin Ballard wrote:
> In general, I’m not a fan of &*, and I like auto-borrowing (autore
>> To what?
> `*`
...But only if you change the deref operator to something else.
Bikeshedding thread! :P
On Mon, Nov 18, 2013 at 7:27 PM, Patrick Walton wrote:
> On 11/18/13 4:23 PM, Ziad Hatahet wrote:
>
>> ...and possibly change `~`.
>>>
>>
>> To what?
>>
>
> `*`
>
>
> Patrick
>
> _
And by replace I mean we could relegate the current tutorial to an
"advanced" tutorial or somesuch.
On Thu, Nov 14, 2013 at 12:30 PM, Benjamin Striegel
wrote:
> I would welcome such an effort, and suggest that it live as its own
> project, outside of the Rust repo. We real
I would welcome such an effort, and suggest that it live as its own
project, outside of the Rust repo. We really aren't set up currently to
handle rapid and frequent documentation changes. Once it gets to a
reasonable level of maturity we could then give it a mention from the main
tutorial, and the
> but why is it valid inside the same scope as illustrated in the code
example?
One use is to allow you to alter the mutability of variables as needed
(often referred to as "freezing" and "thawing"):
let x = 2; // this is immutable
... // do stuff that requires x to be immutable
let
> Except I cannot find them.
The dynamically-sized type posts are sort of scattered all over Niko's
blog. You can start here:
http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/
for a general overview.
On Fri, Nov 8, 2013 at 1:38 PM, spir wrote:
> On 11/08/2013 0
> I would like to take steps to move to that world post Rust 1.0.
I'd be interested to read more about this, and the reasons why it must be
deferred until after 1.0. Is it just "too much work to do right now", or
does it require some broader ambitious feature (HKT, etc)?
On Fri, Nov 8, 2013 at 1
I can't answer your questions, but I do want to say that this is very
interesting!
> Rust compression is about 1.8 times slower, decompression is about 3
times slower than gzip.
Have you tried profiling this to see where our bottlenecks are? It would be
great if we could use this as an opportunit
Before you give the presentation, would you mind showing it to us here? I
for one would be happy to review your code and make sure it's up to date.
On Thu, Oct 31, 2013 at 5:04 AM, KAMI911 KAMI911 wrote:
> Hi Folks, (sorry for cross posting),
>
> I am a Hungarian contributor to Mozilla. Next we
> you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB on
64 bit).
Actually, goroutines have a default stack size of 8kb since 1.2.
Also, applicable to this discussion, in 1.3 Go will be moving away from
segmented stacks to contiguous growable stacks:
https://docs.google.com/doc
1 - 100 of 207 matches
Mail list logo
