FRESH

Hacker News

map::operator[] should be nodiscard

83 points by jandeboevrie

by junon

4 subcomments

For the Rust inclined, [[nodiscard]] is #[must_use], if you were confused.
Anyway, this article illustrates a great reason why C++ is a beautiful mess. You can do almost anything with it, and that comes at a cost. It's the polar opposite ethos of "there should be one clear way to do something" and this sort of thing reminds me why I have replaced all of my systems language needs with Rust at this point, despite having a very long love/hate relationship with both C and C++.
Totally agree it should be marked as nodiscard, and the reasoning for not doing so is a good example of why other languages are taking over.

by nialv7

2 subcomments

C++ operator [] is poorly designed: index, and index+assignment should be two different operators, and indexing alone should never insert new entries into the map.
Languages like D [0] or Rust [1] get this right.
[0]: https://dlang.org/spec/operatoroverloading.html#index_assign... [1]: https://doc.rust-lang.org/std/ops/trait.IndexMut.html

by reactordev

3 subcomments

My pet peeve with c++ is exactly this. Either it’s not wise to call release, or it is (under circumstances) and yet the developer has no idea whether their scenario applies (tip: it doesn’t, 90% of the time).
The stdlib is so bloated with these “Looks good, but wait” logic bombs.
I wish someone would just draw a line in the sand and say “No, from here on out, this is how this works and there are no other scenarios in which there needs a work around”. This is why other systems languages are taking off (besides the expressiveness or memory safety bandwagon) is because there are clear instructions in the docs on what this does with examples of how to use it properly.
Most c++ codebases I’ve seen the last 10 years are decent (a few are superb) and I get that there’s old code out there but at what point do we let old dogs die?

by dundarious

0 subcomment

There is no need to compromise in order to support pre-C++17, you don't need `try_emplace` when the value is like bool and hence doesn't benefit from move semantics -- plain old `insert` is exactly equivalent, and has existed since std::map's inception.

by fn-mote

0 subcomment

Title could be “ugly C++ idioms prevent map::operator[] from being [[nodiscard]]”.
Many of the uses are in Google’s codebase.
Overall very technical- interesting if you are a library writer or maybe if you care about long term improvements in your C++’legacy codebase.

by rwmj

1 subcomments

https://en.cppreference.com/w/cpp/language/attributes/nodisc... .. in case anyone else was wondering. It seems to mean the compiler should warn if you ignore the result except by an explicit cast to void.

by themafia

1 subcomments

Ah, and because this is C++, the standard map having typed template parameters, which could be a non pointer, they're forced to make operator[] have this semantic:
Returns a reference to the value that is mapped to a key equivalent to key or x respectively, performing an insertion if such key does not already exist.
Which is a bit of a surprise coming from mostly C and Go.

by feelamee

1 subcomments

> sometimes that’s actually what you meant — you’re calling it only for its side effect. Back in 2022, Stephan T. Lavavej estimated of unique_ptr::release that “90% of discards are a bug, but 10% are maybe valid…
What are these 10% valid cases? Does someone have an example

by j1elo

1 subcomments

C++ could try to approach the "stability without stagnation" model.
Add an opt-in compiler flag --edition='26' which, when used, applies the breaking changes defined for C++26. Then users like Google or others who have been (ab)using some features for their side effects can decide to stay on the older versions.

0 subcomment

by dooglius

0 subcomment

`try_emplace` is not a huge improvement since it overloads the existing keyword "try" to mean something pretty different. Should be `emplace_if_absent`/`insert_if_absent` but changing the API of stdlib would require going through a huge formal process

by ivanjermakov

4 subcomments

Another default that Zig got right: every non-void result must be handled.
https://github.com/ziglang/zig/issues/219

by juliangmp

0 subcomment

That is an actually terrible pattern, the standard should mandate nodiscard on operator[]. Or maybe finally cast that cursed operator implementation into hell where it belongs.
But alas, existing code is considered sacred in the C++ cult so we must never ever inconvenience anyone maintaining legacy code, no matter how broken it is.

by jesse__

0 subcomment

lol .. add one more reason to the overflowing fountain of reasons to not use anything in std