Patrick,
Nice work! I'm still digesting your full mail.
With respect to the pattern-names-as-type problem, I don't know if
restricting the pattern name to be an identifier is the right thing to do.
Would we be adding that restriction for all fn items, or just those that
appear in traits? There
I think checked integer overflow could be a good idea, presuming the cost
is reasonable, but I am somewhat skeptical of having it be enabled or
disabled on a module-by-module basis. This would imply that if I move a
function from one module to another, it stops working? It seems surprising.
Having
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.
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 closure in place? It seems
semantically
On 26/04/2013 17:22, Alex Bradbury wrote:
On 26 April 2013 16:15, Erik S sw...@earthling.net wrote:
For how rarely used continue is, four extra characters don't much matter.
The time savings from not having to check the documentation to confirm what
the keyword is will outweigh four characters
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
On 26/04/2013 3:07 AM, Niko Matsakis wrote:
I think checked integer overflow could be a good idea, presuming the
cost is reasonable, but I am somewhat skeptical of having it be enabled
or disabled on a module-by-module basis. This would imply that if I move
a function from one module to another,
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
On 25/04/2013 10:42 PM, james wrote:
This always concerns me - the design will tend towards having state on
the stack etc and 'pull' processing rather than focussing on a clean
design for a chain of state machines that handle 'push' of data coming
from AIO completion events.
I think push and
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 26/04/2013 8:24 AM, Felix S. Klock II wrote:
(Felix-Hulk would appreciate it if further discussion on this fork of
the thread had a subject line that reflected its content.)
Tech-lead-graydon asks that we _not_ revisit 'loop', on this thread or
any other. We've been over it so many times
* Graydon Hoare:
How much of a performance penalty is it worth? I believe you can trap
this in C presently with a gcc flag too (-ftrapv); but it's a flag
rarely turned on.
GCC cannot use the OF flag, but LLVM has overflow-checking
instructions, and Clang actually emits instructions using the
On 04/26/2013 09:04 AM, Patrick Walton wrote:
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
On 04/25/2013 06:09 PM, Vadim wrote:
What if Result implemented the Drop trait and fail()'ed in drop()
unless it's been disarmed by calling some method (get_err?) which
indicates that the error has been observed?
I've had a few bits of code recently that called for this sort of
pattern
Hi,
2013/4/26 Patrick Walton pwal...@mozilla.com
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
On 04/26/2013 02:34 PM, Mikhail Zabaluev wrote:
Hi,
2013/4/26 Patrick Walton pwal...@mozilla.com
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
I share your concern. It's likely that Rust tasks will never scale as well
as Erlang and I suspect that we will ultimately want an async API that does
not impose the expense of 1 task per I/O stream. I hope though that the
current approach will scale 'pretty well'.
Is there something
On 26/04/2013 6:47 PM, Huon Wilson wrote:
This change would double or triple throughput of random f64 generation
on 64-bit platforms compared to using the 32-bit algorithm (and
increase it 10-20x compared to calling the rng in the runtime, as is
done now). On this note, f64s are generated by
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
As I have some interest in using RNGs in Rust, I'd like to chime in on
this.
The extra traits like RandomDistribution would be a good thing,
especially if it would be possible to plug a different, custom generator
than the one provided and use the custom generator with code that simply
calls
21 matches
Mail list logo
