On 6/4/12 4:56 AM, David Rajchenbach-Teller wrote:
I actually meant the functions called by the implementation of `remove`.
For instance, `copy` generally does not have to return anything
meaningful.
I see. However, I'm not sure I agree. I think `copy` ought to return
something that
On 6/2/12 6:06 PM, Niko Matsakis wrote:
On 6/1/12 2:59 AM, David Rajchenbach-Teller wrote:
The other problem is that the function may not have enough information
to determine what is locally unrecoverable. I believe that `remove` is
a good example of issues whose recoverability depend on the
On 12-06-01 5:47 AM, David Rajchenbach-Teller wrote:
My main concern is that we would end up with a Rust used in-the-wild
without either guidelines, library or mechanism for handling non-fatal
issues.
Yeah. We'll have to pin down a technique and use it widely through the
stdlib when we're
On 6/1/12 2:59 AM, David Rajchenbach-Teller wrote:
The other problem is that the function may not have enough information
to determine what is locally unrecoverable. I believe that `remove` is
a good example of issues whose recoverability depend on the context.
I'm not sure I understand what
On 5/29/12 4:57 PM, Niko Matsakis wrote:
This code seems wrong... what if an error occurs as part of the call to
`copy()`, for example?
The idea is to simply propagate errors that take place as part of
`copy`, in a ML/C++/Java/Haskell manner.
[...]
In general it seems there are three classes
On 5/29/12 5:52 PM, Benjamin Striegel wrote:
* 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
On 5/30/12 5:35 AM, Joe Groff wrote:
On Tue, May 29, 2012 at 7:57 AM, Niko Matsakis n...@alum.mit.edu wrote:
In general it seems there are three classes of errors
- globally unrecoverable (just call `fail`)
- locally unrecoverable (return a `resultX,Y` type)
- recoverable (pass in
On 5/30/12 3:41 AM, Graydon Hoare wrote:
Hi!
Sorry I've been away, I wanted to talk about this issue, or, well, kinda
just remind you and others in this conversation that there is (in my
mind at least, and in the bug tracker[1]) a plan for how to do this.
I've been continuing to assume this
As promised, I have attempted to rewrite my original function |move|
with a mechanism that would let us define issue-handling policies. This
mechanism is inspired by both the current thread and the previous thread
on exceptions, a few months ago.
So far, the result is not too convincing yet, but
This code seems wrong... what if an error occurs as part of the call to
`copy()`, for example?
As a kind of experience report, I have been using `result` types for
those parts of the compiler where errors must be recoverable rather than
just being reported to the user and papered over. I
* 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
On Tue, May 29, 2012 at 7:57 AM, Niko Matsakis n...@alum.mit.edu wrote:
In general it seems there are three classes of errors
- globally unrecoverable (just call `fail`)
- locally unrecoverable (return a `resultX,Y` type)
- recoverable (pass in handler or error reporter)
If you have
This conversation reminds me of Alexandrescu's talk about D's scope keyword:
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D
It looks like a graceful syntax for handling all sorts of nested error and
failure cleanup...
On May 25, 2012 3:00 AM,
On 5/25/12 5:43 PM, Kevin Cantu wrote:
This conversation reminds me of Alexandrescu's talk about D's scope keyword:
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D
It looks like a graceful syntax for handling all sorts of nested error
and
On Fri, May 25, 2012 at 7:16 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
On Fri May 25 18:01:25 2012, Patrick Walton wrote:
On 05/25/2012 08:43 AM, Kevin Cantu wrote:
This conversation reminds me of Alexandrescu's talk about D's scope
keyword:
On 5/25/12 10:16 AM, David Rajchenbach-Teller wrote:
What's the difference between |scope| and Rust's resources, exactly?
scope would be executed unconditionally at the end of the current
block, while the rules for standard Rust RAII are somewhat more complex
and depend on the initedness of
On 5/25/12 10:28 AM, Patrick Walton wrote:
There's a hidden dynamic flag created by the compiler
Hit send too early. There's a hidden dynamic flag created by the
compiler to track initedness for each variable.
Patrick
___
Rust-dev mailing list
On 5/25/12 10:28 AM, Patrick Walton wrote:
I've been toying with the idea of changing standard Rust RAII to
execute this when the variable goes dead (in the classic compiler
liveness sense) and introduce a scope keyword for something more
like C++ or D RAII in which the liveness of the
On 05/25/2012 03:00 AM, Bennie Kloosteman wrote:
On Thu, May 24, 2012 at 9:16 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
On 5/24/12 12:40 PM, Bennie Kloosteman wrote:
* The system _must_ not prevent developers from calling C code from Rust.
* The system _must_ not prevent
I thought Rust was not going to implement C++ style exceptions . are
these scopes not very similar ? Do you unwind the stack etc when you
are nested deeply within a scope and a fail occurs ?
Also more importantly can you safely handle tasks that were created in
the now to be unwound scopes ?
On 5/24/12 12:40 PM, Bennie Kloosteman wrote:
* The system _must_ not prevent developers from calling C code from Rust.
* The system _must_ not prevent developers from passing a pointer to a
Rust function to C code that will call back to it.
* The system _must_ not prevent, some day,
On 05/24/2012 06:16 AM, David Rajchenbach-Teller wrote:
On 5/24/12 12:40 PM, Bennie Kloosteman wrote:
* The system _must_ not prevent developers from calling C code from Rust.
* The system _must_ not prevent developers from passing a pointer to a
Rust function to C code that will call back to
Actually, one of the conclusions of our previous discussion is that
Java/C++/ML-style exceptions are probably not what we want for Rust. I
seem to remember that we also concluded that using failures as
exceptions was probably not the right course.
Hence this new thread :)
Let me put together
On Wed, May 23, 2012 at 2:47 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Actually, one of the conclusions of our previous discussion is that
Java/C++/ML-style exceptions are probably not what we want for Rust. I
seem to remember that we also concluded that using failures as
On 05/23/2012 05:47 AM, David Rajchenbach-Teller wrote:
Actually, one of the conclusions of our previous discussion is that
Java/C++/ML-style exceptions are probably not what we want for Rust. I
seem to remember that we also concluded that using failures as
exceptions was probably not the right
I am currently implementing a low-level API for file handling, for the
Mozilla Platform. This API is based on libc/winapi (which do not have
exceptions) but itself throws exceptions in case of errors.
This causes any number of amusing/error-prone situations, in which the
implementation of the API
Are exceptions a good model for systems programming ?
- legacy C programs cant call you without a wrapper which translates
all possible exceptions
- unwinding a stack is probably not a good idea in a kernel or when
you transition into protected/user mode.( I know of very few kernels
that use
27 matches
Mail list logo
