Hi everybody,
after using Rust for the last few months to get used to it (I really love it),
I recently started to play around with the new I/O, especially the networking
stuff. I'd say that I'm familiar with how std::rt.:io, std::task and std::comm
works. However I'm not sure how I should hand
There have been some recent grumblings [1] about the use of conditions in the
new runtime's I/O system. It was decided awhile back [2] that we'd try out the
use of conditions for error handling in the new runtime. This has manifested
itself in the `io_error` and `read_error` conditions inside of th
On 10/16/13 11:02 AM, Alex Crichton wrote:
All that being said, we're not making much progress without an idea of where to
possibly go next. Right now, the current idea is to create an Error trait and
have I/O operations return Result instead of Option. This would
mean that Reader/Writer and othe
+1 here too. I agree with what Alex said about conditions. They're useful for
when you can actually recover from the error gracefully, but for generic error
reporting they're kind of a PITA.
-Kevin
On Oct 16, 2013, at 11:16 AM, Patrick Walton wrote:
> On 10/16/13 11:02 AM, Alex Crichton wrote
+1 on getting rid of IO conditions. I'd be okay with a Result based API. If
we change it over, we should have a tutorial that goes over how to deal
with Results to make it less painful for people (e.g. using or_return!
macros).
I'm not a huge fan of implementing Reader for Result, etc.
One thing t
What about the idea of making Result cause task failure if it is destroyed in
the error case? (as opposed to destructuring it)
This just needs a simple language change to add an attribute that would be
applied on Result to declare that it's OK to destructure it and cause drop() to
not be called
On 10/16/13 1:44 PM, Bill Myers wrote:
What about the idea of making Result cause task failure if it is
destroyed in the error case? (as opposed to destructuring it)
For a long time now I've been wanting to make unused non-unit return
values a warning. I think this would be a perfect time to d
This seems rather heavy-weight to me. I’d much prefer if such a thing was
opt-in, e.g. by a function attribute that says the return value must be handled.
-Kevin
On Oct 16, 2013, at 2:12 PM, Patrick Walton wrote:
> On 10/16/13 1:44 PM, Bill Myers wrote:
>> What about the idea of making Result
On Oct 17, 2013 8:12 AM, "Patrick Walton" wrote:
> For a long time now I've been wanting to make unused non-unit return
values a warning. I think this would be a perfect time to do that...
I would love this to be the case. It's the biggest problem I had with Go's
error handling: that it's far too
On 10/16/13 3:31 PM, Chris Morgan wrote:
1. Is there a functional difference between the lines `let _ = f()` and
`let _foo = f()` (assuming no usage of the variable)? These will
probably become common if this check is in place.
There's no difference except that "let _" runs the destructor
imme
Hello! I was thinking a bit about macros, and I had an idea for a kind
of syntactic sugar that might be useful to have. I also posted this to
the issue tracker at https://github.com/mozilla/rust/issues/9894.
# Current situation
Right now, rust knows about two kinds of macro invocation:
ID
Hi Tim,
Thanks for posting these. I haven't listened to the audio, but I read
through the slides and I like your presentation. For me, it is a good
reminder of why Rust is so cool.
I don't know about other users (survey time, anyone? [?]), but my background
is mostly C++ and Java. The notes ab
In general I'd favor anything that would help with
https://github.com/mozilla/rust/issues/9358 - that is, allow more eDSL-ish
macros. Writing `foo!!(...) { ... }` has the cost of the extra `!` but that
really isn't too bad.
That said, I wonder why do macro invocations require the outer set of
pare
On Wednesday, 16 October 2013, Chris Morgan wrote:
>
> I would love this to be the case. It's the biggest problem I had with Go's
> error handling: that it's far too easy to just ignore a return value
> accidentally. (Truth to tell, the problem is far worse in Go because for
> some reason they deci
On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton wrote:
> There's no difference except that "let _" runs the destructor immediately
> whereas "let _foo" runs the destructor at the end of the block. (This is
> admittedly subtle.)
>
>
I tried the following code snippet, but nothing got printed out.
On Thu, Oct 17, 2013 at 2:06 AM, Ziad Hatahet wrote:
>
>
> On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton wrote:
>
>> There's no difference except that "let _" runs the destructor immediately
>> whereas "let _foo" runs the destructor at the end of the block. (This is
>> admittedly subtle.)
>>
>>
Thanks for the quick response :)
--
Ziad
On Wed, Oct 16, 2013 at 11:08 PM, Daniel Micay wrote:
> On Thu, Oct 17, 2013 at 2:06 AM, Ziad Hatahet wrote:
>
>>
>>
>> On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton wrote:
>>
>>> There's no difference except that "let _" runs the destructor
>>> immed
As I understand it, there is a high incentive to have macros be
tokenizable and parseable without needing to expand them - it's a
necessarily if we ever want importable macros (Can't resolve macro
imports if you can't parse the source).
Hence the requirement to have explicit brackets and the nee
18 matches
Mail list logo
