On Fri, May 30, 2014 at 2:35 PM, Oleg Eterevsky wrote:
> I can see the advantages of this solution. The only thing I don't see
> is how to pass any meaningful state with an error.
Not sure if you know this, but you can pass any object to the
single-argument version of fail!:
http://doc.rust-lang
> Personally, I've found exceptions too unwieldy. As I mentioned, the issue of
> catching an exception is "now, how do I recover ?".
In my experience it's not really a problem. Usually you just
gracefully report an error and either exit the program, or write error
to log and stop the operation.
On Fri, May 30, 2014 at 2:01 AM, Oleg Eterevsky wrote:
> > Since browsers were brought up, here is the Google C++ style guide on
> exceptions:
> >
> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
>
> As someone who works for Google, I can attest, that exceptions are
> e
> Since browsers were brought up, here is the Google C++ style guide on
exceptions:
> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
As someone who works for Google, I can attest, that exceptions are
encouraged in Google style guides for Python and Java and the main
reas
On Thu, May 29, 2014 at 7:10 PM, Oleg Eterevsky wrote:
> The projects in C++ that forbid exceptions are doing so not because of
> some prejudice, but because exceptions in C++ are unsafe. In Java
> standard library exceptions are ubiquitous.
If you mean checked exceptions, I hear that they're qui
There are lots of cases even in production code where you just read
something without error checking each and every IO call and just catch
an exception on the higher level.
On Thu, May 29, 2014 at 2:59 PM, comex wrote:
> On Thu, May 29, 2014 at 5:22 PM, Oleg Eterevsky wrote:
>> a = int(f.read_li
>> let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap();
> This isn't doing the same thing as the C++ code.
Is there a shorter code to read an integer?
On Thu, May 29, 2014 at 2:50 PM, Daniel Micay wrote:
> On 29/05/14 05:22 PM, Oleg Eterevsky wrote:
What would be Rust a
The projects in C++ that forbid exceptions are doing so not because of
some prejudice, but because exceptions in C++ are unsafe. In Java
standard library exceptions are ubiquitous.
On Thu, May 29, 2014 at 2:32 PM, Patrick Walton wrote:
> Exceptions, and stack unwinding in general, are not accepta
On Thu, May 29, 2014 at 5:22 PM, Oleg Eterevsky wrote:
> a = int(f.read_line())
> let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap();
It depends what you mean by 'required.'
For a production project, I think it would be a good idea to have
separate error messages for EOF an
On 29/05/14 05:22 PM, Oleg Eterevsky wrote:
>>> What would be Rust alternative, except passing the errors all around
>>> parser? Doesn't it grow parser code by at least 50%?
>
>> Haskell has no exception, it has Monads instead. Rust reuses Option and
>> Result (Maybe and Either in Haskell) with g
Exceptions, and stack unwinding in general, are not acceptable in many
systems projects. Many, perhaps most, C++ projects turn off exceptions.
This is true of all browser engines I know of, as well as games and OS
kernels--essentially the niches where C++ is the strongest. The primary
reason is
>> What would be Rust alternative, except passing the errors all around
>> parser? Doesn't it grow parser code by at least 50%?
> Haskell has no exception, it has Monads instead. Rust reuses Option and
> Result (Maybe and Either in Haskell) with great success.
For all my love to Haskell, I would
I'm looking forward to read this article.
Thanks for the link to CargoResult. I am still not sure how this error
is pass from the failing task...
On Thu, May 29, 2014 at 11:53 AM, Daniel Fagnan wrote:
>> With things like try! and the various helper methods on Result/Option,
> passing errors arou
> With things like try! and the various helper methods on Result/Option,
passing errors around is supposed to be easier than in other
languages. I haven't done much with it, so I don't know how well it
works.
I can attest to it working quite well.
> What would be Rust alternative, except passin
On Thu, May 29, 2014 at 2:32 PM, Oleg Eterevsky wrote:
> What would be Rust alternative, except passing the errors all around
> parser? Doesn't it grow parser code by at least 50%?
With things like try! and the various helper methods on Result/Option,
passing errors around is supposed to be easie
> Overloaded functions are unnecessary in Rust. In C++ they are heavily used
> because of templates use duck-typing, but Rust uses explicit interfaces
> (typeclass-like) which makes it unnecessary.
I agree. This is one of the main use cases for overloaded functions in
C++, and it is irrelevant t
Hi,
On 29.5.2014 02:38, Oleg Eterevsky wrote:
2. What about exceptions? Is it a design decision not to support them,
or are they planned for some future version? I understand, that
exceptions make memory management more difficult, but maybe there are
ways to restrict their usage to avoid problem
> It happens even for this:
>
> struct Test {
> a: int
> }
>
> impl ToStr for Test {
> fn to_str(&self) -> String {
> self.a.to_str()
> }
> }
>
> As you can see, Test is not implementing Show, so I assumed that I
> could implement ToStr instead. I suspect that there is somewhere an
> impl
Thanks for the detailed reply.
I agree that overloaded functions can be used to shoot yourself in the
foot. Fortunately, I haven't yet seen any code that I would care to
read, designed so badly that overloaded functions would do essentially
different things depending on the number or type of argum
On May 28, 2014, at 5:38 PM, Oleg Eterevsky wrote:
> 4. It looks like vectors can be concatenated with + operations, but
> strings can't. Is it deliberate?
Partially. It's fallout of all the changes that strings have been going through
lately. And [PR #14482][] reintroduces + for strings, but i
On Wed, May 28, 2014 at 10:17 PM, Oleg Eterevsky wrote:
> Suppose, I want to add a new argument to a function in a
> backwards-compatible way. In Python I provide a default and everything
> works fine. In C++ or Java I write something like
This came up a few days ago in the discussion about Qt bi
Thanks, I already read some parts of documentation. It is good, though
I found the navigation a bit confusing. I also looked at the sources
for libcore and libstd on GitHub, they are very readable. (Compared
to, for instance, STL.)
By the way, I remembered one more question that I had:
I am a bit
> When writing functions for others to use, you don't want to require them to
> have a String, since that requires a heap allocation.
By no means. I'd prefer the same functions to work both on str and
String. It should be possible to achieve it via traits.
> This is because ToStr is implemented
>> Maybe it makes sense move mut their? Or distinguish mut as a variable
>> qualifier vs const as a propery of type?
> The way it is implemented in Rust is necessary for memory safety.
Are there any articles on this? I'd like to know more. :)
On Wed, May 28, 2014 at 5:48 PM, Patrick Walton wrote
Thanks for your answers. Can't say I understand or agree with all the decisions.
> 1. Not everyone prefers overloaded functions, or default arguments.
Suppose, I want to add a new argument to a function in a
backwards-compatible way. In Python I provide a default and everything
works fine. In C++
You can also read and search the docs and easily see the Implementors (and
even click on them to get more detailed documentation AND even have 1 click
access to the [src] ) :
http://doc.rust-lang.org/0.10/std/to_str/trait.ToStr.html
If you find the docs are lacking a bit, then let the maintainers
On Wed, May 28, 2014 at 5:38 PM, Oleg Eterevsky wrote:
> 3. It seems like almost any string operation requires as_slice().
> Can't various string methods be also implemented for String?
>
When writing functions for others to use, you don't want to require them to
have a String, since that requir
On 5/28/14 5:38 PM, Oleg Eterevsky wrote:
7. The usage of mut is a bit confusing. It is supposed to be used as a
qualifier for a variable, but it quickly becomes a part of the type,
when you define functions like
fn test(something: &mut Something)
Maybe it makes sense move mut their? Or distin
A few quick intro answers. Just the high level, not comprehensive.
1. Not everyone prefers overloaded functions, or default arguments. I
know pcwalton has strong feelings about the first, so I'll leave him
to that :)
2. Design decision. Basically, we take Erlang's philosophy: recovering
from erro
Hi!
I've just recently started learning Rust. Here's a few questions that
I have after writing about a hundred lines of code:
1. Why neither overloaded function, nor default values for arguments
are supported? In statically typed language overloaded functions are
quite safe and convenient. Also,
30 matches
Mail list logo
