That's sad. Having migrated from C++ to golang a few years ago, I find defer vastly inferior to C++ destructors. Rust did it right with its drop trait, I think it's a much better approach
The proposed C defer is scope-based unlike Go. So in the spirit of OP article, you can basically hand roll not only C++ destructor as defer {obj.dtor()} but also Rust Drop as defer {obj.notmoved() ? Drop()}
I mean, you just write all your scopes as `(func() { })()` in go, and it works out fine.
Adding `func() {}()` scopes won't break existing code usually, though if you use 'break' or 'continue' you might have to make some changes to make it compile, like so:
Although that is true, the author has expounded at lengths on the unsuitability of RAII to the C programming langage, and as a big fan of RAII the explanations were convincing.
* cannot return errors/throw exceptions
* cannot take additional parameters (and thus do not play well with "access token" concepts like pyo3's `Python` token that proves the GIL was acquired -- requiring the drop implementation to re-acquire the lock just in case)
I think `defer` would be a better language construct than destructors, if it's combined with some kind of linear types that produce compiler errors if there is some code path that does not move/destroy the object.
I was wondering if the beta checkbox the same thing as setting the ActiveCodePage to UTF-8 in the manifest, but the docs[0] clarify that GDI doesn't adhere to per-process codepage, but only a single global one, which is what the checkbox sets.
Bit of a shame that you can't fully opt-in to be UTF-8 with the *A API, for your own apps. But I think for the issues highlighted in the post, I think it would still be a valid workaround/defence-in-depth thing.
Hrm. I think I had few OS/2 boxes amongst some old games I took to sell to a video game antiquarian, and I think I left it there but they didn't seem interested in them.
Frankly I don't remember which language they were, either english or finnish. I had both the red and blue boxes (was it, with windows support or not?), and other was unopened.
I usually preferred english versions myself, as I learned computers with english, it was more comfortable with me. Also IBM had some rather odd choices on some words versus Microsoft, which could be jarring (was it Umpilevy for hard drive, as opposed to Kiintolevy or Kovalevy in most other places).
One year (must of been 1997 or so?) IBM had a crazy marketing campaign at Assembly[0], where they practically just handed out the boxes to anyone who would take them. If they had handed out finnish version, I would be surprised if they were that hard to come by.
Is the term "Barrel file" somehow in common use? I've never heard of it (not a js dev though).
I would expect some kind of "umbrella file", "public interface", "reexport facade", or something along those lines.
Yes it's common terminology in the modern js/ts ecosystem.
It makes sense because your gathering modules into a single "barrel". We already have plenty of gang of four word vomit terms we don't need anymore.
I find my self disagreeing quite strongly, I would hate that default :/
I find all kind of code folding massively throws off my spatial sense of the code. And if I'm browsing random code, then I often need to see the body too, to see if this is the place the work is done, or is it behind some abstraction down the line.
Perhaps I don't need it as much on c++ codebases, as the headers in a sense are that already. And Rust codebases I've dabbled in haven't been quite that big or overwhelming.
The outlineview/(the popup on top of buffer in many editors that lists the outline) is enough to finding my place in a file I feel lost. And if just looking how to use a lib, there is often some API documentation that helps along finding the right things (even if just barebones doxygen or rustdoc).
I'm sure this is as much of a habit thing as other editor preferences. Still I find it surprising how many people like code-folding :)
