On 1/31/13 6:33 AM, Benjamin Striegel wrote:
+1 to this. Option 8 was always the best-case syntax, and prefixing an
apostrophe on lifetime names is entirely inoffensive.
I like this as well.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 1/31/13 11:43 AM, Graydon Hoare wrote:
On 13-01-31 11:27 AM, Patrick Walton wrote:
On 1/31/13 6:33 AM, Benjamin Striegel wrote:
+1 to this. Option 8 was always the best-case syntax, and prefixing an
apostrophe on lifetime names is entirely inoffensive.
I like this as well.
As awkward
Hi everyone,
With the revamp of the scheduler underway, I'd like to propose a change
to the way C functions work.
Currently, we generate a shim and a stack switch for every function call
from Rust to C and likewise from C to Rust, except for functions
annotated with `#[rust_stack]`. These
On 1/31/13 3:41 PM, Brian Anderson wrote:
There's also the problem with failure after switching stacks. Right now
there is a guard in the stack switch that catches exceptions thrown by
foreign code and aborts the process, which makes this bogus:
do stackswitch {
fail;
}
We could remove that
On 2/1/13 11:02 PM, Brian Anderson wrote:
In the library we add this sort of function that simply guarantee that
the closure has some amount of stack available.
do reserve_stack(Standard) { rust_task_fail(); }
do reserve_stack(Tiny) {... }
do reserve_stack(Large) { }
do
On 2/2/13 4:50 AM, Michael Neumann wrote:
Ultimately we never often want a stack to be increased in size as this
seems to be a quite expensive operation. Calling a function that crosses
stack space
boundaries (i.e. when it has to alloc new stack space) inside a loop
might severly affect
On 2/4/13 11:34 AM, Vadim wrote:
Hi,
I saw a post
http://www.reddit.com/r/programming/comments/17hqg4/a_little_bit_rusty_practical_approach_on_rust/c86xyor
by Patrick Walton last week on Reddit in which he implied that it is
possible to convert Rust enumerator function into a Java-style iterator
On 2/4/13 12:57 PM, Vadim wrote:
So right now there is no way to implement, say, lock-step iteration of
two containers, without first copying contents of one of them into a vector?
Not using the normal iteration protocol. Some containers (for example,
treemap, IIRC) have methods that will
On 2/4/13 9:08 PM, Samuel de Framond wrote:
Regarding syntax, since the lifetime is annotating a type, would a
lifetime suffix be feasible? For example, T is a pointer to T and
T'lt could be a pointer to type T with a lifetime of lt
I don't know :/
This was covered earlier. Suffixes tend to
On 2/5/13 10:59 AM, Brian Anderson wrote:
I suggested removing a few that weren't being used much (classes, infer,
kindchk, linearity, typestate). Is the division here just wrong? After
removing those I suggest it looks like just A-typesystem and A-regions
remain. Are there hot areas in the type
On 2/10/13 2:51 PM, Brandon Mintern wrote:
I recently decided to start contributing to Rust, and to that end, I
grabbed the code and grepped for FIXME. One of the issues I came across
was #4423: Make a version of char::escape_unicode that doesn't
allocate
Hi everyone,
When writing functions that interoperate with C code, I tend to find
myself importing the same few functions over and over. I'd like to see
how everyone feels about a few extensions to the prelude:
* c_int, c_long, c_void, etc.
* ptr::null().
* cast::transmute().
I feel like
On 2/18/13 9:56 PM, Ashish Myles wrote:
As traits are not parametrized by integers, and macros don't seem to be
the right tool for this, is there some other language feature that could
help me get a similar effect?
You need to use macros right now. There has been quite a bit of
discussion of
On 2/21/13 8:33 AM, Ashish Myles wrote:
O wow, I don't know how I missed that. Coming from other languages,
though join seem to be the common name for this. Even the following
search does not bring up any reference to connect.
Hi everyone,
Based on some discussions today, I'd like to float the idea of merging
the Cell and Mut types into a single type called Cell. The reasoning
here is basically that the two types are very similar in functionality,
and the distinction between lowercase-m mut and capital-M Mut seems
On 2/22/13 9:44 AM, Martin DeMello wrote:
On Thu, Feb 21, 2013 at 10:54 PM, Patrick Walton pwal...@mozilla.com wrote:
(4) `with_mut_refR(self, fn(mut T) - R) - R`: yields a mutable
reference to the interior of the cell, failing if the cell is empty or is
borrowed immutably;
Does this mean
On 2/27/13 7:36 AM, Niko Matsakis wrote:
### Treat empty structs the way we treat enum variants?
Perhaps we should just not parse a declaration like:
struct X {}
instead one would write something like:
struct X;
or
struct X();
Much as you write
enum Foo { Y }
This would be a
On 2/27/13 4:04 PM, Niko Matsakis wrote:
All my recent pull requests (and those of many others, I suspect) have
failed due to Windows Error 101 (e.g., [1]). I don't know what this is
but I doubt it's related to my various changes. Anybody know what this
error means? A brief Google search did
Hi everyone,
There is currently a feature whereby custom enum variant discriminants
can be specified:
pub enum Foo {
Bar = 1,
Baz = 2,
Boo = 3,
}
The sole use of this is casting from the enum to an int:
println(fmt!(%d, Bar as int)); // prints 1
This
On 3/1/13 11:51 AM, Graydon Hoare wrote:
It's also to represent enums known-to-C++ with the same values when
projected into rust types.
It'll always be a less-than-faithful translation, though, because C++
enum values don't have to correspond to any of the variants. You can
even represent
On 3/2/13 4:48 PM, Renato Lenzi wrote:
Hi there.
How can i cast from int to float?
that is:
let x = 3
let mut f = 3.0
f = f * x
this doesn't work... i have to change from int to float... is this possible?
Use `as`; e.g. `f = f * (x as float)`.
Patrick
On 3/13/13 2:00 PM, Benjamin Striegel wrote:
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.
Because the ABI is part of the type and not
On 3/22/13 5:10 PM, Martin DeMello wrote:
Since this is breaking everything anyway, how about syntax to let the
match run inside the enum namespace? e.g.
enum Color { Red, Green, Blue }
fn main() {
let x = Color::Red;
match Color::{x} {
Red = ...
On 3/22/13 4:51 PM, Patrick Walton wrote:
* `::` will show up for many casual uses of enums. e.g.
enum Color { Red, Green, Blue }
fn main() {
let x = Color::Red;
match x {
Color::Red = ...
Color::Green = ...
Color::Blue
On 3/23/13 10:52 PM, Chris Peterson wrote:
To reduce the number of rust keywords, I offer the lowly colon as
alternative syntax for the `as` keyword.
I'd like to use the colon for type ascription (i.e. an *assertion* that
a value has some type), which is different from a cast. This would be
On 4/4/13 2:45 PM, Jeaye Wilkerson wrote:
Howdy,
I've been tinkering with Rust generics lately and, unfortunately, they
seem very limiting. Coming from C++, I expect from generics what
templates provide: A plug-in-this-type-in-and-see-if-it-compiles (
On 4/4/13 3:05 PM, Vadim wrote:
What's so confusing about this? I agree that parameter modes had too
many options to think about, but this should be mostly transparent to
the user.Perhaps to the programmer semantics should stay the same as
if parameter was truly passed by value (i.e. no
On 4/6/13 8:14 PM, Ben Kelly wrote:
One of my motivations for looking at this was the long build times
required to compile larger crates. For example, if you touch a single
file in libstd then rustc currently has to rebuild the entire crate
which takes 45 seconds on my laptop:
Unfortunately,
On 4/8/13 9:47 AM, Heri Sim wrote:
Has anyone here taken a look at this yet?
http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/
Just came in on 6 April 2013 for rust 0.6 . Read it a few days back
and it had instantly gotten me interested in Rust.
On 4/8/13 6:45 AM, Heri Sim wrote:
Thanks Patrick for the great explanation.
Where can I find the typical usage examples of the select operation in
the pipes module?
http://static.rust-lang.org/doc/core/pipes.html#function-select2
I guess what remains is the inference for dynamic calls on
On 4/10/13 5:43 AM, Artella Coding wrote:
Hi does rust do tail call optimization? The reason I am asking is that
the following tail call recursive implementation results in a stack
overflow. Thanks.
Not in the general case. But the WIP patch I have to use the machine
return value may allow
On 4/11/13 2:36 PM, Jeremy Huffman wrote:
Hi,
I am considering Rust for a particular use case in which I would be
doing lots of concurrent requests that would spend most of their time
blocked on network I/O in foreign C calls. I may be mistaken but I
think a task that blocks like this would
On 4/12/13 7:48 AM, Benjamin Striegel wrote:
Browsing the web today I found this short article on the Epoch
programming language:
https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme
I'm not a GC expert so I'm not sure if it has any applicability to Rust,
but perhaps someone
On 4/19/13 7:44 AM, Alexander Stavonin wrote:
Do we have any possibility to do something like this or only owned
values can be send?
You can mark your data as serializable and use flatpipes. This gives you
the ability to send managed values, at the cost of a copy on send.
Essentially it's
On 4/23/13 7:48 AM, sw...@earthling.net wrote:
Performance should be about the same when using F-division:
* Performance will go up for division by constant powers of two.
* Performance will stay the same for division by compile-time constants,
since these are transformed by the compiler
On 4/23/13 8:11 AM, Niko Matsakis wrote:
Thanks for your proposal. We've been through a number of rounds with the
lifetime syntax, including an earlier scheme that was quite similar to
what you propose in some regards (there was a single anonymous lifetime
parameter that was used whenever you
Hi everyone,
There's been consensus lately that `core` and `std` are somewhat
misnamed. `core` is really the standard library--the one that would be
specified in a specification if we had one. `std` is an extras library
and may well end up sliced up and moved to various packages.
So it
On 4/23/13 9:44 AM, Erick Tryzelaar wrote:
There are still a couple things in std that depend on rustrt:
arena.rs http://arena.rs
dbg.rs http://dbg.rs
net_tcp.rs http://net_tcp.rs
rl.rs http://rl.rs
test.rs http://test.rs
time.rs http://time.rs
uv_ll.rs http://uv_ll.rs
Can we include moving
I've refactored the Rust grammar to get it as close to LL(1) as I could.
I made some minor language changes along the way which should not break
code, but there are a few things that are still preventing me from
making it LL(1):
1. Explicit self and patterns-as-arguments require two tokens of
On 4/24/13 8:04 PM, Graydon Hoare wrote:
My skill at grammar-factoring is ... minimal, but I thought you could
generally factor anything that's just a common-prefix situation like
these by introducing new rules that go one (common) token further and
then decide between the two remaining possible
On 4/25/13 12:08 AM, Alex Bradbury wrote:
On 25 April 2013 06:25, Patrick Walton pwal...@mozilla.com wrote:
Note that the refactorings I made resulted in a grammar which isn't that
great for tooling or parsing in many places. In particular the contortions
needed to make
On 4/25/13 9:12 AM, Graydon Hoare wrote:
Longer term, I would like whatever grammar we wind up denoting as
canonical / documented / spec'ed to be as (re)target-able as possible.
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse
On 4/25/13 9:23 AM, Felix S. Klock II wrote:
On 25/04/2013 18:12, Graydon Hoare wrote:
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse under any
framework we retarget it to.
I'm a fan of this choice too, if only because the
On 4/25/13 3:46 PM, Brian Anderson wrote:
enum FileStream {
RtFileStream(rtio::FileStream), // Not an fd_t, a boxed wrapper
around uv/rt handles
FileSimulation(~Stream),
NullFileStream
}
With this factoring though you are going to be duplicating a lot of
logic for FileStream,
On 4/25/13 5:29 PM, Brian Anderson wrote:
It's almost taboo here, but we could consider adding catchable exceptions.
I would be in favor of catchable exceptions, for what it's worth.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 4/26/13 6:53 AM, Gábor Lehel wrote:
Probably a crazy idea, but would it be possible to do something where if
the parent task launches a child task, and then does nothing else except
wait for the child to finish, it's not actually implemented by launching
a new task, but instead by calling the
On 4/25/13 10:42 PM, james wrote:
If not, I wonder if there should be more effort on the AIO layer first,
and then consider a synchronous shim on top.
That's exactly what's being done.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
So here are my ideas. They are very worse-is-better at this point.
* Failing to perform a basic I/O operation should result in a call to
the `io_error` condition (default behavior: fail task) and should set an
internal flag saying that this stream is dead. Stream constructors like
`open`
On 4/27/13 1:24 AM, Diggory Hardy wrote:
What the...
There's better things to innovate on than renaming 'continue'. Sometimes I
think rules get taken too far. Perhaps the fact this has been such a long-
running argument is evidence of a problem.
For what it's worth, I am still in favor of
On 4/27/13 4:06 AM, David Bruant wrote:
I believe too this is doomed to happen. Firefox is under a huge struggle
to remove as much as sync IO code as possible as part of the Snappy
effort [1].
This is a completely misleading comparison. Firefox's sync I/O *blocks
the entire main thread of the
On 4/27/13 8:49 AM, Lee Braiden wrote:
This would be a relatively ugly approach, to my way of thinking. Why
should a dead stream be returned at all, if the code to create it
failed? Why should I be able to call write() on something that could
not be created?
Two reasons:
1. If `open`
On 4/27/13 11:36 AM, Lee Braiden wrote:
On 27/04/13 18:51, Patrick Walton wrote:
On 4/27/13 8:49 AM, Lee Braiden wrote:
This would be a relatively ugly approach, to my way of thinking. Why
should a dead stream be returned at all, if the code to create it
failed? Why should I be able to call
Hi everyone,
The reactions to this bug on impls [1] have caused me to think that the
current treatment of paths in generic type and trait implementations is
something of a wart and perhaps should be reworked. Specifically, the
problem is that this:
implT MyTypeT {
fn newU() -
Just thought I'd give the mailing list a heads up that ~string,
besides being ugly, is generally inefficient: it allocates a string on
the heap and frees it when it goes out of scope. There are no
optimizations that eliminate the allocation.
If you need to compare a `~str` against a constant
On 4/28/13 10:57 AM, Lee Braiden wrote:
Really? Strings can't just be compared with == ? To be honest, that
alone is almost enough to put me off the language -- not only is it ugly
and unwieldy, but it suggests a lot of limitations in the language's
memory model / type system / operator
On 4/28/13 12:45 PM, her...@gmail.com wrote:
It is very easy to create a language that is unwieldy, but hard to
create something KISS simple that can be adopted, and that will be
praised for its cleanliness and elegance.
If the basic things are not simple, a language will be relegated to
On 4/30/13 11:26 AM, Gábor Lehel wrote:
Couldn't this be relaxed? In other words allow dynamically sized `str`
as a type (and perhaps similarly for other dynamically sized types), but
prohibit those things specifically which would be problematic, i.e.
using it in ways that would require knowing
On 5/1/13 10:29 AM, John Clements wrote:
Currently, the set of doc comments includes (among other things)
lines beginning with three slashes, *unless* they're entirely
slashes. Presumably, this is to ensure that things like
/ // Time to go get some coffee!
... aren't
Hi everyone,
There's consensus that `@` (imported from Haskell) is a bad binding
operator for patterns, because it leads to the confusing-looking `@@`
in, for example:
struct Foo {
field: int
}
...
match foo {
foo@@Foo { field: x } = ...
}
However,
On 5/4/13 3:55 AM, james wrote:
It might be development policy, but it seems to me a terrible idea.
How do you fork a requirement? (or discussion thereof?)
How do you fork a design? (or discussion thereof?)
It seems to be the old 'show me the code'. :-(
I think it's totally fine to bring up
On 5/15/13 8:37 PM, Huon Wilson wrote:
Hi,
I spent a few hours hacking together a performance graph thing[1] that
takes the compile and test times from the auto buildbot and plots it,
ala arewefastyet.com.
It's not great, but it's something. (It apparently shows that #6417[2]
cut the compile
On 5/18/13 3:27 PM, Brian Anderson wrote:
The new scheduler is still far from complete, but there is enough in
place that we can start to get a sense for its performance
characteristics. I've done a simulation of making message-passing calls
into a layout task and have some preliminary numbers.
On 5/18/13 3:27 PM, Brian Anderson wrote:
* layout task places the response message payload into the 'oneshot'
buffer send by script.
* layout does an atomic swap with full fence to check the status of the
script task and sees that it is not waiting for the response message
(it's in the work
On 5/29/13 2:18 PM, Gábor Lehel wrote:
Hello list,
Currently Rust has different default visibilities in different places:
- `mod` items are private
- `struct` fields and `enum` variants are public
- `trait` methods are public
- `impl` methods are private
- `impls for` are public (by necessity)
On 5/30/13 8:40 AM, Tommy M. McGuire wrote:
On 05/30/2013 04:56 AM, Niko Matsakis wrote:
Another example is in Hashmaps, where we offer two variants on the
find-or-insert pattern:
fn find_or_insert(mut self, K, V) - OptionV
fn find_or_insert_with(mut self, K, fn(K) - V) - OptionV
On 6/5/13 9:09 PM, Daniel Micay wrote:
I think extending the built-in `for` loop to work with external iterators
should be considered, because right now the verbosity discourages using them
and makes borrow checking more painful than it has to be.
It could treat functions as internal iterators,
On 6/6/13 8:55 PM, Corey Richardson wrote:
Hello all,
As of 5d2cadb, the default allocator used in the runtime on all
platforms is now jemalloc. This provides significant allocation
speedup on Windows and Mac, and good speedup on Linux. Additionally,
memory usage should be lower and (untested)
On 6/9/13 3:39 AM, Rémi Fontan wrote:
it seems to compile compiles, but the following did not work:
let v = Vec2df:new(1.0, 2.0);
This feature is planned but not yet implemented.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 6/10/13 9:51 AM, Huon Wilson wrote:
We've been converting a large number of freestanding functions in str
to methods (and a few in vec too), and *deleting* the original
functions. I know Rust is not quite aiming for backward-compatibility
yet, but this might be a bit too much... it gives
On 6/15/13 1:26 AM, Graydon Hoare wrote:
I saw some more speculation on how to make rustc not-so-terriby-slow to
compile today, including dramatic structural changes like splitting it
into sub-crates. Please don't do this; it's papering over much more
readily solvable problems. A 80kloc library
On 6/15/13 10:09 AM, Björn Steinbrink wrote:
This seems to be due to the landing pads for the function calls. Each
contains one more call to drop, so the code grows quadratically with the
number of allocations.
I had a patch that's bitrotted to turn off table-driven unwinding on
failure
On 6/15/13 11:59 AM, Graydon Hoare wrote:
Because it was being proposed as a solution to speed, but:
Well, in my case, I often start swapping, which kills codegen
performance. So it would help my particular use case. (It would also
help us land the GC.)
Patrick
On 6/15/13 6:18 PM, Björn Steinbrink wrote:
OK, so I have a hackish version [1] that mostly handles growing
landing pads within a single scope (in nested scopes, the parent cleanup
blocks are already reused). Mostly because there seems to be some
problem with e.g. ~int. Consecutive let x = ~5
On 6/24/13 2:14 AM, Michael Woerister wrote:
* There is the trans::adt module and the Repr enum which look very
promising. It does not provide all the information I need (e.g. it will
include generated fields, but does not explicitely specify where they
are located, just in comments (enum
On 6/28/13 11:23 AM, Niko Matsakis wrote:
Specificity is the cost of non-virtual dispatch. However, if it is
truly undesirable in some cases, we can eventually permit you to
return `~Iteratorint`, once ~-objects work properly.
They basically do now (in master), no?
Patrick
On 7/1/13 5:32 AM, Corey Richardson wrote:
Variable width floating point code is also dangerous - frequently code
has implicit assumptions about accuracy. Using floating point
correctly is already hard enough, introducing variable width types
makes it even harder.
I proposed this in the past,
On 7/4/13 12:58 PM, Daniel Micay wrote:
You can create many threads with fixed stacks, they just start off
using 4K instead of however much smaller our segmented stacks will be.
A scheduler will just be more expensive than a regular lightweight
task.
The 15-100% performance hit from segmented
On 7/5/13 10:42 PM, Ashish Myles wrote:
And an additional question.
3. What is the rationale in having both Copy and Clone? Can one
provide an exhaustive list for where one would want to use Copy
instead of Clone/DeepClone? I tried to use clone everywhere, but I
needed T : Copy + Zero to be
On 7/8/13 4:14 AM, Corey Richardson wrote:
Given a rustc::middle::resolve::CrateMap, a syntax::ast_map::map, and
a syntax::ast::Ty, how can I determine what real type the given
ast::Ty refers to?
Typechecking uses the functions in `astconv.rs` (particularly
`ast_ty_to_ty`) to transform an AST
On 7/10/13 1:55 PM, Niko Matsakis wrote:
Technically, this design does not require pushing mutability into
`Cell`, but if we do that we gain the advantage that Cell is the only
one who has to worry about tripping write barriers.
That's genius. +1.
Patrick
Hi everyone,
Currently there's a problem with repeated vector expressions (`[0,
..n]`): the value must be copyable. I would like to change this to
implicit copyability changing as part of the migration to `Clone`, which
makes this even more restrictive.
This makes it impossible (without
OK, after talking with Felix and Niko (thanks!) here's a proposal.
* Whenever we borrow an `@mut` to `mut`, add it to a borrowed set for
the duration of the borrow.
* Objects in the borrowed set are grayed before each incremental GC slice.
* Objects in the borrowed set are scanned during
On 7/13/13 7:27 AM, Michael Woerister wrote:
So, I thought it might be a good idea if I tried to remove the
spannedT struct altogether and added the span field directly to the
types that are wrapped at the moment. If needed, I would also add a
Spanned trait that allows to abstract over anything
Keep in mind that fmt!'s interface is misdesigned at the moment: with the
current interface the result is allocated on the heap even when the output is
destined for a file or the screen. This is one of the bugs that resulted in
poor performance (an order of magnitude slower than Python) on
On 7/15/13 12:39 AM, Michael Woerister wrote:
Thinking about it, side table or not, the spannedT struct would go
away in its current form anyway, right? So it should be a step in the
right direction, to gradually remove its usages. Since spannedT
affects how nodes using it are accessed in
On 7/14/13 1:04 PM, Svetoslav Neykov wrote:
·“unsafe” is not a normal block and doesn’t return a value, can’t be
used as an expression. This made it impossible to wrap the unsafe casts
from fixed memory locations to borrowed pointers in macros. Instead I
had to use inline functions and assign
Just a quick note that I have a pull request in the queue to remove the
copy expression in favor of the clone method. Please try to avoid
using copy in your pull requests, or you will cause mine to bounce.
(It has already bounced somewhere between 5 and 8 times, I lost count.)
Thanks,
Patrick
On 7/24/13 7:59 PM, Jeaye wrote:
We had some discussion recently about reforming the for-loop syntax
since we'll be switching it to external iterators and it's a bit
deceptive to the user to be writing a lambda-pattern there.
Have we yet considered C++11's approach to this?
for name :
On 7/26/13 8:54 AM, Michael Woerister wrote:
To me this seems very much like a slightly clunky way of emulating
inheritance (with a lot more typing involved at definition and usage
sites). Field accessor functions or traits can alleviate some of this
clunkyness at the usage site; however, at the
On 7/28/13 3:06 AM, Björn Steinbrink wrote:
Hi,
out of curiosity (and because perf results hinted me to do so), I tried
compiling rustc with disabled LLVM assertions. Compile times were
reduced by about 25%-30%. For example stage1 librustc takes about 2m12s
with assertions enabled and 1m38s
On 7/28/13 4:00 AM, Armin Ronacher wrote:
Hi,
On 28/07/2013 11:13, Huon Wilson wrote:
As I understand it, this is planned[1] as part of the
move-GC-to-the-libraries proposal[2]: that is, provide some traits with
lang-items (like Eq, Add, Drop, etc.) which, for example, give library
pointers
On 7/27/13 7:51 AM, Gábor Lehel wrote:
Thoughts?
Niko and I discussed and debated this exact proposal a few months ago :)
The outcome was that it wasn't worth it for a few reasons:
* The FFI really wants sweet syntax for C pointers.
* `'unsafe` isn't really a region, as it doesn't fit in
On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:
Hi,
I'm observing rust development for some time, and I must say it slowly
encourages me to use it. Especially the progress from Perl-like syntax
to more sane and quiet form is enjoyable.
That said I wonder why the function definition has form:
fn
On 7/30/13 10:05 AM, Graydon Hoare wrote:
Trickier call. We don't allow type ascription inside patterns, only at
the outermost level. I think we found that our grammars were
sufficiently similar that intermixing them inside one another produced
ambiguities, though I don't remember off hand which
On 7/30/13 10:39 AM, Graydon Hoare wrote:
Really? How would you resolve it? You have to decide after seeing {x:
which grammar to switch into parsing. Currently we go with the pattern
grammar there.
Struct literals have to be prefixed with the type of the struct (as we
don't have structural
On 7/30/13 11:34 AM, Graydon Hoare wrote:
You still have to decide what to parse after you saw Foo {x:. If it's
subpat, then you can't put a type ascription there. Maybe that's
semantically unproblematic since Foo uniquely types its fields. But that
breaks the symmetry with type-follows-: in
Hi everyone,
Brendan Eich emailed me expressing a preference for `GC` over `Gc`.
I think now is as good a time as any to have the bikeshedding debate :)
I've noticed two styles for acronyms in type names: Java style
(HTTPServer) versus .NET style (HttpServer). Currently we are usually
using
On 8/2/13 7:38 PM, Tom Lee wrote:
Bikeshedding is right ;)
I'm probably a weirdo but I like the Java style when the type name is
the acronym in its entirety, but the .NET style when you mix it up with
other stuff.
e.g. I prefer GC to Gc, but then I prefer SimpleHttpServer to
SimpleHTTPServer
On 8/2/13 1:10 AM, Ivan Ristić wrote:
I am starting to play with Rust, but I got stuck early on with a trivial
TCP client example. (There's a few server examples out there, but I
couldn't find a single working client anywhere. I tried the archives,
the tests, etc.)
Sounds like #3599:
On 8/12/13 8:25 AM, Tom Lee wrote:
:) I can appreciate that, but I'm still not really convinced that this
problem deserves more syntax.
That said, I might hate for..else less if it used something other than
the 'else' keyword. *shrug*
It seems to me that a big benefit of macros in Rust is to
201 - 300 of 608 matches
Mail list logo
