Item — HN Reader

> I wish they would have some kind of super strict mode for C or C++ where compilation fails unless you somehow fix things at the call sites to tell the compiler the behavior you want explicitly.

The C++ language committee _does not_ want to add more annotations to increase memory safety.

2 comments

Not even annotations. The committee standardize this https://en.cppreference.com/w/cpp/container/span/operator_at

So they clearly doesn't care so there's no point convincing them.

The committee tends to also provide bounds checked interfaces ( https://en.cppreference.com/w/cpp/container/span/at ). But that requires people read the documentation, and based on the number of people who I see write "std::endl" when they really want "'\n'", I don't have much hope for that ("std::endl" both sends '\n' to the stream, and flushes it; people are often surprised about the stream getting flushed).

We've known since the 80s that programmers almost always choose the more ergonomic interface and telling people they're holding it wrong doesn't scale.

Besides, throwing an exception is a terrible way to do range checking. There's a huge number of projects out there banning exceptions that would benefit from safe interfaces.

> Besides, throwing an exception is a terrible way to do range checking. There's a huge number of projects out there banning exceptions that would benefit from safe interfaces.

I thought "banning exceptions" would mean fno-exceptions, turning the throw into an abort - that's pretty good for a systems programming language, no?

What other way would you propose?

Make it explicit that the API can fail. Panicking is not acceptable in systems programming. Force me to handle all the cases.

I'm not trying to be provocative, but I genuinely am not seeing what the benefit of this "doctrine" is if the end result is a bunch of if else statements that do nothing, but bubble the error up and then exit the process anyway.

Panicking is in no way different from say Undefined Behavior, with the exception that panicking tends to be "loud" and therefore fixed promptly.

There are systems banning exceptions that aren't allowed to crash. The software running cars and planes for example, or LLVM.

EDIT: HN formatting is absolute horrendous so here's a pastebin https://pastebin.com/raw/BUJBAqc1

> but bubble the error up and then exit the process anyway.

What is so bad about this? Its only a problem because all languages are not ergonomic. Even Rust. Here's how to do it properly in my mind.

What I am proposing is not Rust, but what I wish Rust would have been.

First, you have functions that cannot fail

``` fn not_failable() -> Result<u32, ()> { return 0; } ```

Notice that the function still returns Result<T,E> but the error is (). Now what happens if the function can fail?

``` fn failable(value) -> Result<u32, () | A | B | C | D> { if value == 0 { return Ok(0); } else if value == 1 { return Err(A()); }else if value == 2 { return Err(B()); }else if value == 3 { return Err(C()); }else if value == 4 { return Err(D()); } } ```

Notice that we don't have to specify a type for the errors, they are just the unions of all the error types that is possibly returned by the function. This union could be inferred by the type system to be ergonomic (meaning it can be omitted from the type signature for ergonomic purposes)

You might think that this is almost like exceptions. And you are right, but this is where exceptions got wrong, the user of this function.

When using this function, you are forced to handle all the possible error types (exceptions) returned by the function

``` fn use1() -> Result<u32, () | C | D> { match failable() { Ok(v) => {} Err(A) => {} Err(B) => {} e => return Err(e), } } ```

Notice 2 things:

1. You are FORCED to handle all the possible exceptions. 2. You can specify which exceptions you want to handle and what you throw back. The difference to try/catch here is just the syntax. 3. The function signature can be automatically be duduced by the fact that A and B are already handlded, and that this function can only throw C or D now.

Now you might complain about ergonomic, why can't things just blow up the moment anything bad happens? I propose a trait that will be automatically be implemented for all Result<T,E>

``` impl Unwrap for Result { fn unwrap(self) -> u32 { match self() { Ok(ok) => return ok, Err(err) => panic!("error"), } } } ```

Which means that you can simply do this,

``` fn fail_immediately() -> Result<u32, ()> { return failable().unwrap(); } ```

Or, if you want to bubble up the errors, you can use ?

``` fn fail_immediately() -> Result<u32, A | B | C | D> { return failable()?; } ```

Ending your string literal with \n is much easier than using std::endl.

The comment was about bracket notation versus .at()

My only opinion on the \n versus std::endl discussion is that people set overly aggressive linting rules that always flag endl even when flush is intended.

Several programming languages can testify to the fact than a Benevolent Dictator For Life is not a panacea. Several more than testify that having a Committee to design the language is likewise not a panacea. Perhaps uniquely C++ can clarify for us that both is in fact worse than either alone.

Same applies to C.

Do you see Brian and Dennis dominating WG14 meetings? Nope. They moved on, Bjarne Stroustrup never did. After his initial prototypes and his first book about C++ he's written lots more books and papers, he's lectured classes, he's given huge numbers of talks, all of them about his baby, C++. If you ask WG21 people directly they'll insist he's just one vote (ah yes, JTC1 consensus "voting") but for example WG21 says it will heed the "advice" of its Direction Group, a self-selecting handful of people which is dedicated to following advice from a book written by Bjarne and weirdly always giving exactly the same advice as Bjarne, which makes sense because its most notable member is Bjarne but this advice is signed "The Direction Group" ...

It's like being surprised that the UN Security Council keeps making decisions which favour Russia.

It doesn't change the fact C is equally a design by committee language with all the negativity it entails.

In fact, WG14 very clearly has acted against Dennis when he submitted papers that could have improved C's safer.

Maybe his fat pointers proposal was not good enough, but apparently is wasn't something worth improving upon either.

C authors indeed moved on, first with Alef (which granted had a few design issues), Limbo and finally Go, as C as being driven by WG14 was no longer their thing, C on Plan 9 isn't even C89 compliant.