More backports

[pfeatherstone]

It would be cool to add some backports of:

• std::optional
• std::expected

With monadic interfaces. These allow you to write really nice APIs

[davisking]

Yeah these are great. I was about to be like "they are in C++14 so we can totally use them!" but then realized it's only in C++17 :|

Anyway, IDK, how about we just switch dlib to C++17 next year? Or like, how long has it been since visual studio supported C++17?

[davisking]

Like maybe we can go C++17 now basically. It's 2023 after all, maybe it's time.

[pfeatherstone]

Yeah that would be great! The only thing is that not all compilers support all of C++17. For example, Clang still doesn't support the special math functions from C++17. I'm pretty sure filesystem isn't fully implemented everywhere. So it would be a subset of C++17 to make it really portable.

With regards to backporting std::optional, we could add the monadic interfaces which were only added in C++23. std::expected only made it in C++23. so I still think it's worth adding them.

I've been having a go at std::optional already. It's actually quite hard to get it standards compliant, which has lots of specialisations depending on whether the underlying type is trivially destructible, trivially copyable, not copyable, etc etc. It's painful, but I guess that's what gives you performance in C++, while maintaining good APIs.

[davisking]

Yeah it kinda depends on why you want it. It's to use these things with older compilers that don't have C++17?

[pfeatherstone]

Yes precisely. I don't always have the luxury of a modern compiler. Even if I can't use dlib in its entirety, having a good, solid implementation in dlib, that is standards compliant, and heavily unit tested, means I can always strip it out when needed and have peace of mind it works as expected (because it has to pass the Davis filter)

[davisking]

Yep, makes sense :D

[pfeatherstone]

Update: dlib::optional is done. I'm working on dlib::expected. It turns out, if you follow the standard specification for std::expected to the letter, it is a complicated beast! I do feel sorry for standard library implementers. Implementing these has been an eye opener on what is a good candidate for the standard library. Vocabulary types which are conceptually easy to understand, very useful generally but hard to implement right, such as std::optional and std::expected are good examples. They are constexpr, noexcept where possible, they have few requirements on the underlying types and are properly specialised depending on the type's semantics, are stack alllocated but can also be passed as registers if the underlying type is trivial. All of that is non-trivial to get right (in c++).