A blog post for it from a prominent c++er https://herbsutter.com/2013/04/05/complex-initialization-for...

You've made the choice of (Locked Door, Open Window) ~ (Good SQL usage, XSS Vulnerability) which seems to be an incorrect rebuttal. Your example doesn't contradict "only as strong as its weakest link", here the weakest link is the XSS Vuln.

The "house analogy" can also support cases where the potential damage is not the same, e.g. if the open window has bars a robber might grab some stuff within reach but not be able to enter.

I think this is in response to

> Why should my Dog be able to check out the internal StomachContents of another Dog

This seems to be interpreting the purpose of visibility as controlling the access that actual things represented by objects have. (There could be a non oop-as-real-world-things example here; `UserProfile.equals(UserProfile other)` might access secrets of `UserProfile` that the different actual users are not supposed to see between each other.)

The reason Dog can check the internal details of another Dog is, there's a single file that controls the usage of the fields. If you decide you want to change the semantics of the stomachContents field, you can check all the usages in that file. That's the simple practical reason. The StomachContents thing seems like a confusing analogy, like most that compare OOP to Real World Categorization.

To add on to the defense in another comment,

I don't think the point of the article is a rust-v-python comparison. Sure, unoptimized-python2rust2optimized rust was a part of the clickbait 180,000x title but... - the author explicitly says the python2rust bit is only a factor of 8. - the Python bit is just one section of a pretty long article - the author says they typically start implementing something in Python so... why wouldn't they include their initial implementation?

I don't think this article should be dismissed just for including a simple python implementation- that isn't the point.

> I thought the axiom of choice says that it is possible to obtain an [infinite] set of votes from an [infinite] set of voters each with a non-empty set of choices

The axiom of choice does say this but,

1) This is not where we are applying the axiom of choice

2) You don't need the axiom of choice here: you can always just pick the "voting set" where everyone votes for choice # 1.

The axiom of choice says that the product of infinitely many non-empty sets is empty. This is needed only when you might have a different and non-computable set of choices to make at each step.

Where we are applying the axiom of choice here is: the voting scheme is just a rephrasing of an "Ultrafilter on the power set of a set": https://en.wikipedia.org/wiki/Ultrafilter#Ultrafilter_on_the... This is implied by the axiom of choice in a way that requires some working out (and is sketched in wikipedia). But you can roughly see how the axiom of choice comes about if you start trying to construct a voting scheme (the following is just intuition):

1) We know the result if the number of "Nays" or "Yays" is finite.

2) Pick any set of "Yays" so the number of "Nays" and "Yays" is both infinite. Declare this set (arbitrarily) as a victory for either "Nay" or "Yay"

3) The set in (2) implies that a bunch of other sets are either Nay or Yay by the axioms in the article (e.g. flipping all votes flips the outcome, etc)

4) While there are sets we haven't decided on, repeat steps (2) and (3).

Of course (4) is the whole tricky part, since you have to describe with this "looping forever" means rigorously... but you can see how the idea of "making infinitely distinct choices" comes up.

> The axiom of choice says that the product of infinitely many non-empty sets is empty.

You mean non-empty.

Make A Really QUool EEffect

Undefined behavior is considered worse than crashing, which is typically the alternative when reaching "unreachable" codepaths.

Compare these two blocks similar to the article

   switch (ch) {
   case 'a': do_a(); return;
   case 'd': do_d(); return;
   // ch is guaranteed to be 'a' or 'd' by previous code.
   default: assert(0);
   }

   switch (ch) {
   case 'a': do_a(); return;
   case 'd': do_d(); return;
   default: std::unreachable();
   }

If the programmer is wrong about `ch` in the first one, the program terminates. For the second one, the compiler could change it to be equivalent to

  if (ch == 'a') { do_a(); }
  else { do_d(); }
  return;

If the programmer is wrong here, the program might `do_d()` with unintended consequences. I'd say "going down unintended codepaths" is typically considered worse than crashing.

N.b. fixed last code example- thanks afiori.

I take your point, but you can get the behavior of your first example, while still marking the default branch with std::unreachable(), by asserting the preconditions before the switch. This seems to me to be a pretty general equivalence.

So what does std::unreachable() do here? In this particular case, and with NDEBUG defined and any level of optimization selected, I suspect that, at a minimum, the switch would be replaced as you have shown in all versions - it would take a more complex example to show how std::unreachable() makes a difference. The point is, now we have a choice - and it is one that is being offered without creating any backwards-compatibility issues.

Furthermore, the original function, without assertions, is not guaranteed to crash, with or without std::unreachable(). You need some explicit checks to get a desirable response in the case where a mistake has been made, and that option is just as available whether or not you use std::unreachable().

Therefore, while I agree you have shown that not all broken variants of a given program are equivalent, this does not show that std::unreachable() is harmful.

I suspect you meant to omit the `if (c == 'd')` part in the last example

I get your point, but assert is usually removed in release builds. Abort would probably be better if you want to crash the program.

Let me rebuke just one part of the post: the example with Newton's laws. Of course everyone knows that Navier-Stokes is just a very nice approximation. That doesn't mean that mathematical results about Navier-Stokes can't improve or understanding of the physics side. For instance, if we find a solution which blows up, that may lead us to a correction to the model or (less likely) it may be actually physically realizable.

I'm pretty ignorant of browser stuff, but couldn't the attack be even worse than mentioned in the article?

If the newly opened website has full control over the Facebook tab, can't the attacker directly modify the html in the opener to pop up a form asking for a password? This would be stronger because the address would not change.

Could the attacker reach into the Facebook tab and pull any information from it?

No. You do not have access to the contents of the window because facebook.com is on a different origin.

As this article says, you can change the location of the window.