Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2018-02-01 00:52:00

2018-01-31 20:25 GMT-03:00 Emil Dotchevski <emildotchevski_at_[hidden]>:

> Where is the compile time error? Example?
>

Check the first Outcome tutorials.

This won't compile:

std::cout << (convert(text) / 2) << std::endl;

This will:

OUTCOME_TRY(foo, convert(text));
std::cout << (foo / 2) << std::endl;

You can't forget to handle the error case. You can look at a function and
you'll immediately know if this function can fail or not.

You can't draw conclusions only by looking at anectodal evidence like this.
> If you want to demonstrate that Rust-style error handling is more robust,
> you have to have a control, the same real-world large scale project
> written/designed for using C++ exception handling. Neither of us has a
> control.
>

At least you dropped the "axiomatic belief". But I haven't relied on
anecdotal evidence. I specifically told you to show me /any/ code on Rust
that is as complex as the examples I gave.

C++ allows complexity to just snowball and it is not a opt-in feature. It's
always there. Therefore, you always maintain useless state in your head
when analysing C++ code. Go ask C programmers what they think about C++
exceptions.

So you have to be able to make your point in the abstract, which is very
> difficult. It is especially difficult because using either approach, a high
> quality development team can produce a robust program. But just because
> Google managed to build a phone using Java, it doesn't mean it was a good
> choice.
>

You still ignore the fact that I'm talking about a qualitative (not
quantitative) property: more errors go to compile time errors. I have been
focusing on such aspect since the beginning of the discussion.

It's fact that you can't ignore the error because the code will fail to
compile. Error cases are explicit.

Yes, using exception handling you can make mistakes that would be less
> likely to make otherwise. Also, using C++ you can make a whole lot of
> mistakes you can't make in Java, that's one reason why some people use Java
> and not C++, but this doesn't make them good C++ programmers -- nor it
> means that there is something wrong with C++.
>

Agreed.

There are very many examples of things being very difficult to express in
> C++ while being trivial in another language. There are usually good reasons
> for this, and there are many examples to the contrary. The ability to use
> RAII and exceptions to enforce postconditions is one such advantage.
>

Not sure what kind of postcondition you're talking about this time.

If it is class invariants, you can have them without exceptions.

And just one note about RAII: Rust does have RAII. No GC. A lot about the
language was inspired by C++ knowledge.

I'll point out again that in C++ it is impossible to report an error from a
> constructor except by throwing, and this is a good thing. I assume you
> disagree -- so what do you propose instead? It can't be OUTCOME_TRY, can it?
>

I'm not proposing you to code differently.

I'm discussing exceptions vs Result.

Once I finish this discussion, you'll be surprised by how much opinion we
(me and you) have in common.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/