Stupid people require oxygen to live.

This works fine for me:

function foo() {
  bar[0]="hello"
  bar[1]="world"
  return 1
}
if ! foo; then
  echo "${bar[@]}"
fi

https://onlinegdb.com/xPIFP110w

Are you getting messed up by the way bash handles exit statuses? An exit status of 0 indicates a success and a non-zero exit status indicates a failure (which allows for the different exit statuses to indicate different errors).

So if my_func; then something; fi will only run something when my_func returns 0. In your case, you’re using ! to do the opposite so it only runs when your function returns a non-zero status.

This can be quite surprising if you’re expecting the behavior found in other languages like python or C++ where 0 represents false and 1 represents true.

I see. Yeah, the end cursor can take some getting used to.

The thing that always messed me up when starting out was how deleting any text overwrites the clipboard. It was an odd quirk at first but I kind of like it now.

I still constantly wrongfoot copy and paste regularly

What do you mean by this?

Blue testicles?

It’s useful when vim is being run from a different program or script.

For example, if I run p4 change to create a new Perforce changelist it will open up my editor (which I have set to vim) so that I can enter the CL description and other fields. If I realize I don’t actually actually want to create the CL yet I can use :cq to quit with an error so that p4 knows to abort.

I also have a script I use for diffing a list of file pairs. It runs vimdiff on the first pair of files then if I exit with :qa it will move on to the next pair of files. But if I exit with :cq it will just abort and skip all of the remaining file pairs.

I agree that it’s the most obvious choice, but it also doesn’t work when there are hidden buffers open. :qa! and :cq should always work so they are arguably more correct

What do you use instead?

It makes more sense when you realize it’s based on code.golf submissions. No one is going to create a class like that for a code golf problem. They’re probably not going to create any classes (other than one just to hold the main function).

I’m pretty sure I can do the Fibonnaci one with less code than your simple class. Because these problems are simple enough they don’t benefit from any OOP stuff so you avoid most of the syntactic overhead.

I am surprised it’s not higher in the list since the overhead of setting up a main method is still quite significant compared to most languages. But other than that, these problems can be solved without running into any egregious examples of overhead.