hckrnws
> 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”
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.
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.
C++ is somehow aesthetically dis pleasing, thus mixin idea doesn’t change the needle for me.
That `String` leaks memory, it doesn't have a destructor.
If omitting it for brevity on a website, they could have just shown the signature and commented out the body ...
> That `String` leaks memory, [...]
So does the clone...
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.
std::optional<T&>
It is specified previously in the text that support for references would be nice for optionals.
And unless I'm mistaken C++ 26 gets std::optional<T&> with the preferred representation (ie it's the same size as T& like with Rust's Option<&T> and &T pairing) and the ergonomics are no worse than you'd expect for C++
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.
Because it can also be called with any class that doesn't have the bar method, and good luck deciphering the compiler error for it when it's nested 3 levels deep into some far corner of the STL.
That is what concepts fix. It lets you enforce at build time that `t` does have member `.bar()`.
Comment was deleted :(
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?
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'.
This “mixin” concept uses the CRTP pattern, as mentioned in the post: https://en.wikipedia.org/wiki/Curiously_recurring_template_p...
It actually does have specific applications. That Wikipedia article shows a good example of polymorphic method chaining. In a former life, I worked with Microsoft’s Active Template Library, which is entirely based on this pattern.
And just use concepts and call it a day.
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.
Code with types on the right like this makes me very sad
static
auto create(const char* data) -> Result<String>
static auto
create(const char* data)
-> Result<String>
Types are only nicer on the left when it isn't also annotated with all the other static constexpr [[nodiscard]] nonsense. And left types are actually greppable seperately from variable declarations.
Having both left and right types is stupid, but as a whole right types are easier to deal with
I learned of a cute side effect when one puts the function name on its own line, like above.
In BSD of yore and modern contemporaries, one could often perform `grep '^function'` and end up finding the source file quite easily. I think it also makes using ctags(1) a bit easier too, but not entirely sure on that bit.
FWIW I completely agree, I think -> rt is a very silly idiom in declarations. It’s fine and useful for lambdas.
I cannot disagree more strongly. Putting the name of the function (or method) in the middle of the declaration drastically lowers readability.
C-style type declarations were always the most painful part of reading C.
No they won't. Your example is way more unpleasant to read.
"Mixin?" What's it mixin'?
Crafted by Rajat
Source Code