Really not a fan of the alternative `if` syntax, and I think that the
problem of too many braces applies primarily to `alt` expressions anyway.
Another reason to be wary of your `if` proposal is that it makes Rust's
already-a-little-scary semicolon rules a bit harder to express (you don't
need a
Optional named parameters in function invocations could be a third option,
although of course that introduces a third inflexibility to consider. :P
So, which happens most often?
1) You create a class without any constructor besides property assignment,
and then later introduce a more substantial
So this would basically mean that a function like:
fn wtever(foo: int, bar: str) { ... }
could be called as either:
wtever(1, hello); // tuple syntax
wtever{foo: 1, bar: hello}; // record syntax
Not sure how I feel about invoking a function using a record literal, its'
a little bit elegant
There was an exchange on IRC last week about removing some keywords. It
seemed a bit too broad and open-ended to open an issue for it, but I didn't
want it to get lost entirely.
pcwalton:we could get rid of resource and be, maybe while and log,
although trait will add another
pcwalton:maybe
Here's a summary of Go's subcommands, which could be useful for a starting
point:
build compile packages and dependencies
clean remove object files
doc run godoc on package sources
env print Go environment information
fix run go tool fix on packages
fmt
I'd honestly be ok with going back to vecT or vecmut T for the vector
type and using [T] for the slice, to discourage this hazard.
I think this could be a win for clarity. There are enough potential use
cases here that overloading [] doesn't seem to give all that much benefit.
On Sat, Apr 28,
3.uint() + 4u
Does this parse correctly, or would you need to do (3).uint(), like in
Javascript?
On Wed, May 9, 2012 at 11:32 PM, Niko Matsakis n...@alum.mit.edu wrote:
The `as` operator is annoying for a number of reasons:
- the precedence is non-obvious and hard to get right (3 + 4 as
* The system _must_ not prevent, some day, developers from calling Rust
from JavaScript.
* The system _must_ not prevent, some day, developers from calling
JavaScript from Rust.
I'm not aware of any precedents for calling out of or into Javascript, in
any language. What specific constraints
I think that eholk's work on reimplementing ports and chans as
Singularity-style channel contracts could use a mention, as well as its
current status (16x speedup, or something?)
On Thu, Jul 5, 2012 at 11:13 PM, Jesse Jones jesse9jo...@gmail.com wrote:
Can the difference between the exchange
This feels simpler, yes. But as long as we're talking about presentation,
would it be possible to establish standard terminology to distinguish
between dynamically-sized vectors and fixed-length vectors? People will
tend to simply refer to both as vectors or vecs, and confusion will
result. It
I concur with Patrick.
Short keywords: good
Short identifiers for stdlib APIs: good
Short identifiers for internal variables: bad (but excessively long ones
are just as bad, for different reasons)
On Tue, Jul 17, 2012 at 6:04 PM, Patrick Walton pwal...@mozilla.com wrote:
In short: short
When looking through libcore and libstd, there are some impl methods that
simply delegate to functions elsewhere in the file, like so:
impl extensions of unique_str for ~str {
#[inline]
fn trim() - ~str { trim(self) }
}
Is this a pattern that all the impls in the standard libraries ought
I believe the upcoming LLVM changes can be found in pcwalton's LLVM repo,
in the noteroots-ir branch:
https://github.com/pcwalton/llvm/tree/noteroots-ir
On Tue, Jul 24, 2012 at 12:46 AM, Zack Corr zackcor...@gmail.com wrote:
On 7/22/12, Jed Davis j...@panix.com wrote:
...but that wouldn't
the road (cf Javascript).
I'd be interested to see this happen, but I'd like to see how it works with
unignorable return values. Do you have a branch that we can play with?
On Thu, Aug 2, 2012 at 10:41 AM, Patrick Walton pwal...@mozilla.com wrote:
On 08/02/2012 07:22 AM, Benjamin Striegel wrote
For example, `max()` can be defined as a method like so:
trait Number {
fn max(self, other: self) - self;
}
and then used as follows:
num_a.max(num_b)
or as follows:
import Number::max;
...
max(num_a, num_b)
whichever is more convenient or more aesthetically pleasing.
Very
Ah, thank you for the clarification. I was not aware that such an
operation could occur. (There are no examples of anything like it
in the Tutorial or Reference Manual.)
Be sure that you're looking at the up-to-date docs:
http://dl.rust-lang.org/doc/tutorial.html#structs
Rust struct types
Does adding fake machine insns to the automatic root inference scheme
yield support for moving collectors?
Not sure about your other questions, but this document answers your
questions in regards to moving GCs:
https://github.com/elliottslaughter/rust-gc-notes
The disadvantage was that this
I think I'd actually prefer require in place of extern mod to any use
of the extern keyword. extern should solely be associated with the FFI;
overloading the term to refer to pure Rust code is confusing.
I like this. One more keyword is a small price to pay for clarity. link
could also be used
So will we always have to dereference a ref variable using the asterisk
symbol?
At least until irrefutable patterns are supported in argument lists:
https://github.com/mozilla/rust/issues/3586
On Wed, Oct 3, 2012 at 10:22 PM, Ziad Hatahet hata...@gmail.com wrote:
So will we always have to
(Hi folks, the mailing list has been having some trouble, so I'm forwarding
this on John's behalf.)
-- Forwarded message --
From: John Mija jon...@proinbox.com
Date: Wed, Oct 17, 2012 at 3:04 PM
Subject: GPU programming
To: ben.strie...@gmail.com
Since Rust compiles down to LLVM
that
.raise() is called on a Condition? How will users of an API be expected to
discover all the possible signals that are available to be trapped from any
given function?
On Mon, Oct 22, 2012 at 9:44 PM, Graydon Hoare gray...@mozilla.com wrote:
On 12-10-21 09:50 PM, Benjamin Striegel wrote
I'd like to emphasize that Rust's standard libraries are all somewhat
haphazard to various degrees, so I wouldn't presume that anything that is
currently possible or impossible via the libraries implies any sort of
overarching design philosophy. Though considering how many people seem
eager to
I'm not sure when the MinGW - MSVC switch is happening, but I think
Windows 7 testing would be useful. And maybe Windows XP, depending on how
much trouble that turns out to be. Or is Servo never intended to be
explicitly compatible with XP?
On Fri, Nov 9, 2012 at 4:58 PM, Graydon Hoare
I second the Debian stable and Arch bots. I'd also welcome bots for both
the latest stable Ubuntu and for the most recent Ubuntu LTS. Along with the
CentOS bot, this would give Rust a really solid linux presence.
On Fri, Nov 9, 2012 at 7:58 PM, Ted Horst ted.ho...@earthlink.net wrote:
OSX
Rather than using a function as a constructor, like:
pure fn PairingHeapE: Copy Eq Ord(initial_value: E) - PairingHeapE
{ ... }
let heap = PairingHeap(1);
I believe it's more idiomatic to instead use a static method, as in:
implE: Copy Eq Ord PairingHeapE : Eq {
static fn
Would this trait:
pub trait MapK: Copy Eq Ord, V: Copy {
pure fn get(k: K) - @OptionV;
pure fn put(k: K, v: V) - self;
pure fn delete(k: K) - self;
pure fn traverse(f: fn((K), (@OptionV)));
}
be something that ought to live somewhere in the standard library?
I
Sadly, you should really read this subsequent blog post:
http://smallcultfollowing.com/babysteps/blog/2013/01/15/lifetime-notation-redux/
It turns out that this syntax is ambiguous without introducing a whitespace
dependency. I think it might still be worth it, but I know that a lot of
people
A long time ago, the Rust mode for Emacs would indent match arms by two
spaces, so any two-space match arms are a remnant of that time. I believe
the current convention is to use four spaces for match arms.
On Wed, Jan 23, 2013 at 8:16 AM, Sanghyeon Seo sh4@samsung.com wrote:
Rust compiler
There's already a function to do this:
fn main() {
for int::range_step(0, 10, 2) |i| {
log(error, i);
}
for int::range_step(10, 0, -1) |i| {
log(error, i);
}
}
On Fri, Feb 1, 2013 at 7:28 AM, Alexander Stavonin
Though note that this function is relatively new, you'll need to be on a
recent unstable version rather than 0.5.
On Fri, Feb 1, 2013 at 8:48 AM, Benjamin Striegel ben.strie...@gmail.comwrote:
There's already a function to do this:
fn main() {
for int::range_step(0, 10, 2) |i
Is that the same syntax highlighter that github uses for their gists?
No, Github uses Pygments for their syntax highlighting. And though there
exists a Rust highlighter in Pygments, it's a newer version of Pygments
that Github's Ruby-based Pygments wrapper doesn't yet support.
Though note that
I think it would be useful to address all of these points with real
examples and see if we can come up with solutions if Rust is currently
falling short. For instance, in the imperative API, running external
programs is *really* hideously ugly right now (by the end of the day I'll
have submitted a
So then the only changes to existing code would be:
1) Wrapping the enum definition in a macro and giving it a type.
2) Changing `foo as bar` to `foo.to_bar()`.
Is this correct? Here's an example that I've modified with the new syntax:
https://gist.github.com/bstrie/5064858 . It looks pretty
Also, why can't I use to compare OptionT even if OptionT
implements Ord for T: Ord?
I actually implemented something like this back in December, that enabled
you to use + on any two options as long as their types also implemented +.
But... I forgot to send it upstream. :) I'll revive it later
Hm, well that's unfortunate...
I think that range_rev might just need to be rewritten to get the values in
(i, j] rather than [i, j).
On Tue, Mar 5, 2013 at 11:42 PM, Ryan Hyun Choi ryan.c...@samsung.comwrote:
Hi all,
I have a quick question about using uint::range_rev().
I'd like to
I'll speak up in favor of ditching both const and static for global.
global foo: int = 1;
global mut bar: int = 1;
'global baz
(Though not sure exactly what the 'static region is, does that last one
make sense?)
On Tue, Mar 12, 2013 at 3:44 PM, Graydon Hoare gray...@mozilla.com
Somewhat off-topic, but why are extern functions written as
extern ABI fn(T) - U
Rather than using an attribute?
#[abi = ABI]
extern fn(T) - U
It seems like a very bizarre special case.
On Wed, Mar 13, 2013 at 6:33 AM, Niko Matsakis n...@alum.mit.edu wrote:
A quick opinion
What do you mean when you say that the page is read-only? AFAIK all pages
on the wiki are read+write, and I don't see any controls to change that.
On Mon, Apr 8, 2013 at 11:42 AM, Olivier Renaud o.ren...@gmx.fr wrote:
Hi,
I saw the [wanted libraries] page on the github wiki, and I'd like to
The general guidelines appear to be:
* put opening braces at the end of the line
* indent by four spaces
* restrict lines to 100 characters or less
In the future, the pretty printer may be improved such that it's suitable
for automatically applying these rules, as per gofmt.
On Tue, Apr 9,
Go has not anything like Python's PEP8, but a tool which formats code and
it is being used widely by the projects.
I prefer that Rust would have such tool, replacing the usual compendium
of do's and don'ts that allows interpretation:
I agree that such a tool would be wonderful. However, there
I use it frequently enough for conciseness. I'm having a hard time thinking
of a language that *doesn't* support a construction. Does it cause a
problem with formalizing the grammar?
On Tue, Apr 9, 2013 at 1:04 PM, John Clements cleme...@brinckerhoff.orgwrote:
I've recently become aware of the
It's important to keep in mind that much of the value of calling something
the standard library is so that users *know* that the libraries within
are blessed by the language developers themselves, and therefore gives them
the peace of mind that the code within is featureful, reliable, supported
in
would it be reasonable to restrict the left- and right-hand-sides to
simply be literals?
Literals only? So then would the following be illegal?
static END = 2;
...
match bar {
0 .. END = ...
}
On Wed, Apr 24, 2013 at 6:36 PM, John Clements
I concur, util is one of the ones that I would definitely avoid. It
sounds like somewhere that you would just put code that you couldn't
rightly stick anywhere else.
I like the sound of both prime and platform.
On Wed, Apr 24, 2013 at 11:48 PM, Andres Osinski
andres.osin...@gmail.comwrote:
If
FWIW, I both enjoy and have written things along the lines of `14 + if
(true) {3} else {4}` (a.k.a. Rust's answer to C's ternary operator) and
`for foo.each |a| {f(a)}.bar()` (method chaining FTW). I would be sad to be
forced to wrap either of those in parens.
But more pertinently I worry that
why is continue spelled loop in Rust?
continue violates Rust's six-character policy, and the original keyword,
cont, was undesirable for obvious reasons. Considering how rarely-used it
is (there are eight uses in the whole compiler), the decision was made to
simply reuse loop and save a keyword.
The other option is just to require parameter names on all method
declarations
I honestly wasn't even aware that it was possible to omit the parameter
names when declaring traits (it's not mentioned in the tutorial or in any
code I've ever seen). It makes sense in retrospect, but I wouldn't
Is it conceivable that this is a library that people would like to use
outside of Rust itself? In other words, would it make sense to package this
library in runtimeless/standalone format, and have Rust depend on it via
submodule?
On Fri, Apr 26, 2013 at 9:47 PM, Huon Wilson dbau...@gmail.com
Are explicit `mod`s too heavyweight for this?
On Thu, May 2, 2013 at 6:18 AM, Niko Matsakis n...@alum.mit.edu wrote:
I often find when writing code that I want to introduce sections
into my file. Typically I do this like:
//
A commenter on Reddit seems to think that the state values are twice as
large in the C version, which explains the slower benchmark result:
http://www.reddit.com/r/rust/comments/1e262v/rust_can_be_faster_than_c_for_random_number/c9wd8qb
Still, the revised numbers are very competitive!
On Fri,
Indeed, I think it might be useful to embark on a project to review *all*
the uses of #[inline(always)] that currently exist and determine their
necessity. I too have been guilty of using it where #[inline] alone would
suffice.
On Wed, May 29, 2013 at 11:15 PM, James Miller aa...@aatch.net
This blog post describes how you would achieve this:
http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/
See the section entitled What if I want overloading?
On Sat, Jun 15, 2013 at 5:52 AM, Rémi Fontan remifon...@yahoo.fr wrote:
Hi,
I read that rust does
. I would really like to go
past the first learning curve and proceed to my initial project.
thanks for your help.
Rémi
On Sun, Jun 16, 2013 at 1:15 AM, Benjamin Striegel ben.strie...@gmail.com
wrote:
This blog post describes how you would achieve this:
http://smallcultfollowing.com
All works on most recent Linux Mint, assuming that the correct git revision
is a2db7c15ce9f586164cabb15d83fb3f6bbeb3cf5.
On Tue, Jul 2, 2013 at 11:14 PM, Brian Anderson bander...@mozilla.comwrote:
Oh look at this! It's a 0.7 release candidate!
Would moving away from segmented stacks also allow us to bring jemalloc
back?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
The bug for this is at https://github.com/mozilla/rust/issues/5244 .
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I think Jack's proposal is fine, but as Bennie notes I think it's still
worth discussing whether C#-style formatting would be a better fit for us
than C-style formatting.
I'm a fan of sticking with the fmt! style
Patrick mentions that fmt! currently requires a heap allocation to work, is
this a
This is all fantastic, especially the codegen tests. Does buildbot record
the codegen tests in a way such that they're potentially trackable on
isrustfastyet?
On Tue, Jul 16, 2013 at 8:33 PM, Graydon Hoare gray...@mozilla.com wrote:
Hi,
I've added some new machinery to the testing systems in
AFAICT it should be possible to bypass this auto-filtering by setting up a
filter of your own for messages from rust-dev@mozilla.org.
On Wed, Jul 17, 2013 at 2:42 PM, ori bar toh...@gmail.com wrote:
gmail has recently added a tabs interface in its inbox. For some reason,
this interface
I agree that this is a huge headache waiting to happen. It's our own
version of the const-correctness problem.
We do already have a notion of opt-out kinds via #[no_freeze] and
#[no_send], so this isn't entirely unprecedented.
It would also be good to know how often one needs custom copy
I think at the least we should offer a #[deriving(Basics)] for use on
public types so that people aren't forced to memorize Eq Ord TotalOrd
TotalEq IterBytes Clone (unless we can find a silly SFINAE-esque
acronym... http://www.wordsmith.org/anagram/anagram.cgi?anagram=eottic ).
On Thu, Jul 18,
for pattern in expr { ... }
I really like this notation. And there's actually a better reason for
switching to a new syntax other than it's a bit deceptive to the user to
be writing a lambda-pattern there. Namely, given strcat's plan to allow
iteration automatically on anything that implements
Is it appropriate for all digests to live in extra::crypto?
While I'd hope that anyone actually doing crypto would know better, it
seems Wrong Wrong Wrong to put non-cryptographic hashes in such a namespace.
___
Rust-dev mailing list
I don't agree that the type of a function and the return type of a function
are the same thing (specifically, the type of the function contains the
return type). :) If nothing else, this would make the function signatures
of higher-order functions much harder to read IMO.
On Mon, Jul 29, 2013 at
Come to think of it, it might also make the grammar for function signatures
ambiguous, given that we allow null return types to be omitted.
On Mon, Jul 29, 2013 at 9:18 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
I don't agree that the type of a function and the return type
This would make deeply-nested HOF easier to read, but I'm not a fan of the
way that `fn foo(-int) {` looks for functions with no arguments.
Because I forgot to register my opinion previously, I do like the way that
the current syntax reads in the common case, including the use of the
I'm mostly indifferent. The only reason I slightly prefer the .NET
convention is to avoid confusion with statics (`GC` could easily be a
static, `Gc` could not).
+1 to having Graydon flip a coin. That way we can shift all blame to the
fundamental randomness of the universe.
Well done to all involved!
* Implementing a new HTTP client on top of `rt::io`, possibly using Chris
Morgan's HTTP code, for use in Servo
Will this HTTP lib be included in libextra, or will it be external?
___
Rust-dev mailing list
This looks really great. In general I like the look of the braces. For the
details of the syntax, I think we should borrow as much as possible from
other languages; no need to be very novel in this space. I also don't think
we should worry too much about cases like {: +#10.10d} as long as the
Note that we have an issue open in the bug tracker for this:
https://github.com/mozilla/rust/issues/7746
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Could a macro work just as well here?
On Mon, Aug 12, 2013 at 3:10 PM, Armin Ronacher armin.ronac...@active-4.com
wrote:
Hi,
I was just thinking about that again, and I wonder if that could be used
to create a pattern for initialization literals for collections.
Once we have yield fn
See here:
http://www.cs.virginia.edu/~evans/cs4414-fall2013/pages/ps1.html
Strikes me as a bit of a bad idea, but I'll give the professor points for
audacity. Apparently they're mandating 0.7. Perhaps we should reach out and
offer support to the students? If we can establish a relationship, it
As usual, I'm highly resistant to use of the backtick because Markdown uses
it pervasively. Not only would this make it very annoying to embed Markdown
in strings, it can make it impossible to embed inline Rust code in Markdown
editors. Let's leave the backtick as a metasyntactic symbol.
On Fri,
I think string literals should contain exactly what they contain in their
source form, without any additional processing. If you want to express
characters that are inconvenient to type, you can use control sequences and
a (standard) formatting library to produce them.
I'm actually very
I'd be curious to know if changing rustc -O to rustc --opt-level=3 has
any effect. Which is to say, I'm curious if currently we make any
distinction at all between opt levels 2 and 3.
Also, what version of Rust? I believe our support for
LLVM-SIMD-vectorization-pass voodoo only landed recently.
Is there a use case that necessitates such a feature? The following code
works today:
let a = 1;
let b = 2;
let (a, b) = (b, a);
Not sure why that wouldn't be sufficient.
On Wed, Sep 25, 2013 at 2:50 PM, Marvin Löbel loebel.mar...@gmail.comwrote:
On 09/25/2013 06:37 PM, Diggory
Note that we reserve the dollar sign ($) for use in macros, so it wouldn't
be able to appear in regular Rust code without some sort of escaping
mechanism. I also don't see anything like this happening before Rust 2.0 at
the earliest.
On Wed, Sep 25, 2013 at 2:40 PM, Marvin Löbel
I believe the intention was to allow `mut` in the same places you could
put `ref` today in a pattern match.
I was also under this impression, though I've never seen it explicitly laid
out anywhere. Would be nice to see if the devs are on board with this
extension to the pattern grammar.
I've only skimmed this conversation, but note that the specialness of the
'self lifetime will be going away in the future.
On Mon, Sep 30, 2013 at 10:48 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I see what you mean about the macro - it would get quite complex though.
Regardless of macros,
I'll be in Toronto!
On Tue, Oct 1, 2013 at 5:28 AM, yati sagade yati.sag...@gmail.com wrote:
See you folks in Santa Clara :)
On Tue, Oct 1, 2013 at 2:47 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
I opened a public pad for this info:
We've got just the thing for you! Our bug tracker has a tag for
interesting projects:
https://github.com/mozilla/rust/issues?labels=A-an-interesting-project
Many of these features are things that we'd love to have, but that none of
the official developers have time to complete for 1.0. Some of
You use `rustc` to output LLVM IR (with --emit-llvm) and then compile
with `clang -flto -O3 foo.cc foo.bc` (you need a version close to Rust's
LLVM, 3.3 won't understand the readnone/readonly parameter attributes). If
you're calling the Rust functions from C++ or the C++ functions from Rust
you
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:
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 kami...@gmail.com wrote:
Hi Folks, (sorry for cross posting),
I am a Hungarian contributor to
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
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 denis.s...@gmail.com
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 mut
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
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
ben.strie...@gmail.comwrote:
I would welcome such an effort, and suggest that it live as its own
project, outside of the Rust repo. We really
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 pcwal...@mozilla.comwrote:
On 11/18/13 4:23 PM, Ziad Hatahet wrote:
...and possibly change `~`.
To what?
`*`
Patrick
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 block
...and the conditional form:
loop expr block
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
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
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
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
(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
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 gae...@xeberon.net wrote:
Sorry for this offtopic subject..
Le 30 nov. 2013 20:20, Benjamin
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
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 pcwal...@mozilla.comwrote:
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
1 - 100 of 169 matches
Mail list logo
