BenFrantzDale

> Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge.

What about just putting that sort of thing in human-targeted documentation? Why call it a “skill” and hide it somewhere a human is less likely to look?

(Skills are nice for providing /shortcuts.)

Having it available means we can use it explicitly. For example, I could see a compiler flag making `std::vector<T>::operator[]` be checked and then if profiling warrants, remove the check by explicitly checking if my index is out of bounds and invoking UB. Not saying that’s the pattern people will use, but having an escape hatch makes safer-by-default behavior more approachable.

As a C++ user, shared_ptr is great for some things, but it is an anti-pattern. Shared_ptr<const T> is much much better. The problem is that shared_ptr<T> isn’t value-semantic and so destroys local reasoning. That said, there are places for it, but it’s very easy to make a mess with it.

I’m a huge gain of stlab::copy_on_write<T>, which is fundamentally very similar but which is value-semantic, doesn’t let you make loops, and gives You local reasoning.

I agree. I wish we had to say `int x = std::uninitialized;`

Can you express value semantics in Python, or is everything still passed by mutable reference still and duck-typed at runtime? I’m being flip, and I like Python for some things, but for large robust performant software I find C++ way easier to work with as it works with me not against me to wrangle complexity.

I thought that too. I think the point there was that you don’t have to push this notion as afar as in/out of functions: that just flipping them within a function can be beneficial.

I agrée with them and with you. It looks like they work in some poor language that doesn’t allow overloading. Their example of `frobnicate`ing an optional being bad made me think: why not both? `void frobnicate(Foo&); void frobnicate(std::optional<Foo>& foo) { if (foo.has_value()) { frobnicate(foo); } }`. Now you can frobnicate `Foo`s and optional ones!

For list comprehension, we have (C++23): `std::ranges::to<std::vector>(items | std::views::filter(shouldInclude) | std::views::transform(f))` it’s not quite `[f(x) for x in items if shouldInclude(x)]` but it’s the same idea.

That’s what tests are for. And if `print_table` is factored properly then they won’t want to add flags, they’ll make a new function out of the pieces of `print_table` that has distinct behavior of its own.

If the sub-functions could be reused and people would be tempted to change them, then that’s what your tests are for. In fact, it’s often tricky to test the sun-function logic without pulling them out because to write the test you have to figure out how to trick the outer function to get into certain states. Follow the Beyoncé rule: if you like it: put a test on it. Otherwise it’s on you if someone breaks it.

I totally agree. And you can always write mutating “functions” (what get called “algorithms” in the C++ world), like C++’s `std::ranges::sort(range)`.

I write C++ including the conventions around the strong units library we use. What this article promote as “better” seems pretty bad. They dont like `Money m = new Money(10.0m); decimal amount = m.Amount;` and images prefer `Money m = 10.0m; decimal amount = m;`. While it’s nice to not have to say `new`, the implicit conversion in and out of strong units is terrifying and defeats the purpose. For example, while I generally like C++’s `std::chrono` library, it s `duration` types have a `.count()` member function to extract the number. But if you change the type from `std::chrono::seconds` to `std::chrono::milliseconds`, then `.count()` silently changes from “number of seconds” to “number of milliseconds”. For full safety, you need to name the units to “unpack” them. E.g., `Speed_mmps speed = 10.0_mm / 2.0_s; float speed_mm_per_s = getCount<Speed_mmps>(speed);` where if the type of `speed` changed to furlongs per fortnight, the `getCount<Speed_mmps>` call would either not compile or be correct up to floating-point precision.