HN Reader

> I think the big asterick to all of this design is that my ideal framework would not look like standard C++ but like a slightly weirder Rust stdlib

An interesting option in this space is rpp [1], which bills itself as a “Minimal Rust-inspired C++20 STL replacement”

[1]: https://github.com/TheNumbat/rpp

Code with types on the right like this makes me very sad

    static
    auto create(const char* data) -> Result<String>

Types are a lot more ergonomic on the left - the return type of a function and the type of a variable are very important for understanding and skimming code. When the return type is on the right, it is physically very far from the name of the object and I have to scan the entire line with my eyes to get the same amount of information I would get by just looking at the left column and scrolling down if it were on the left. I am pretty sure in another 20 years types on the right will be regarded as one of the ergonomic fails of current language design. At least, if have to do this, put the type right under the object name, like so:

    static auto
    create(const char* data)
    -> Result<String>

Future readers will thank you.

In a language with ad-hoc polymorphism like C++, mixins seems entirely unnecessary.

You can just declare by convention that a freestanding clone(T x) -> T function should exist for it to be 'cloneable'.

"Mixin?" What's it mixin'?

While I've never really found much practical use for mixins, it is fairly easy to create a runtime system for them in Java. Any interface can become a mixin simply by storing state in a static global hashmap with `this` as the key to the map. Specifically for the map, I would use `Collections.synchronizedMap(new WeakHashMap<>())` so that the map is thread-safe and allows mixin instances to be garbage collected.

It seems messy and even the author of TFA is unconvinced.

How does a mixin compare to role or interface in languages that do not have multiple inheritance?

We've used this pattern for years. It definitely delivers in terms of being lower overhead. I will say that compiler errors can be nonsense though.

GNU C++ once had a system called Signatures, could support mixing in. It was removed. Many years ago now I think.

A signature resembles a class declaration in that it specifies member functions. A signature is never instantiated. Rather any class which has those member functions conforms to the signature, and a signature-typed pointer can point to instances of that class. Thus signatures bring about quack-like-a-duck polymorphism not requiring inheritance.

I don't really see the point when C++ already lets you write

void foo(auto& t) { t.bar(); }

which can be called with any class that has the .bar() method anyway.

That `String` leaks memory, it doesn't have a destructor.

I am curious about this idea, and maybe it’s a “me problem”, but I’m having a very hard time following the article. There’s a lot going on here.

    std::optional<T&>

Can't have optional references in C++. Use either std::reference_wrapper, or just a pointer

"Mixin?" What is that supposed to mean?

C++ is somehow aesthetically dis pleasing, thus mixin idea doesn’t change the needle for me.

A lot of this stuff has been investigated in Mr Alexandrescu's ironically named book Modern C++. Typelists (before variadic templates) recursive templates and componenet-like assembling of classes, etc. I imagine there is a modern-modern-c++ version of Loki library somewhere on github.