Andrzej's C++ blog

> WG21 seems to dearly wish this wasn't so, offering Concepts which pretend to semantics they don't have, such as std::totally_ordered and I'm glad to see your "CanBlah" concept doesn't do this, to be sure all things which match this requirement can, indeed blah() although we've no idea what that can or should do.

I don't understand how random assumptions on what WG21 may or may not think counts as an example (or anything to be honest)

> If something satisfies a Concept, but does not model the Concept then the C++ program is not well formed and no diagnostic is required.

uh... no ?

I think that you are referring to this blog post: https://akrzemi1.wordpress.com/2020/10/26/semantic-requirements-in-concepts/ for which I entirely disagree with the whole premise - the only, only thing that matters is what the compiler understands. The standard can reserve itself the right to make some cases UB, such as when trying to sort un-sortable things just like it can state that adding to numbers can cause UB and that's fine: it's the language's prerogative and is all to be treated as unfortunate special-cases ; for the 99.99999% remaining user code, only the code matters and it makes no sense to ascribe a deeper semantic meaning to what the code does.

> In which case it's your responsibility to ensure you can log this, which of course CanBlah didn't express.

A metric ton of side concerns should not be part of the spec, such as logging, exceptions, etc - everyone saw how terrible and…

Regarding Rust:

> There is another thing I noticed, and I hope someone from the Rust community can correct me if I'm wrong, but it looks like Rust also special cased format_args! in the compiler by making it a built-in. If my understanding is correct, this would make Zig stand out as the only language of the three mentioned here which does not special case string formatting in the compiler and instead exposes enough power to accomplish this task in userland.

It depends what you mean by "userland". Rust has long supported procedural macros, albeit not on stable compiler versions until recently (and still only hackily there). Procedural macros, a.k.a. compiler plugins, are written in Rust, but work differently from compile-time function evaluation. With CTFE, the code running at compile time lives in the same "world" as the rest of the code being compiled, in a sort of pretend version of the target environment where you can't do things like call external functions. Rust compiler plugins are just separate libraries that get compiled for the host architecture and loaded into the compiler process (which is less scary than it sounds; the build process "just works" thanks to Cargo, and Rust's safety ensures you don't stomp on random compiler state). You have access to the full language and can call whatever you want, even do things like file I/O if needed; on the other hand, you're in a separate environment and can't just name variables, functions, etc. from the runtime…

As someone who has deliberately avoided C++ for the last 20 years (in favour of functional programming) I find the discussions of "reference semantics" and "value semantics" (let alone "mutable value semantics") to be quite opaque. It is as if the C++ community has become an enclave of folks who put up with the extreme complexity of C++ and speak a correspondingly tortuous theoretical language.

What the seem to be saying here is that the "subscripting" operation returns a view into its argument, not entirely unlike the concept of a lens. The only thing that view can be used for is directly accessing the the part of the value that is in focus—the view is not itself a first class value, which means that so-called "reference semantics" don't come into the picture.

I don't think they're being evasive or promoting their idea in bad faith. They are just operating in a characteristically arcane way for C++ language design people.

The following blog post helped me start to grasp what this aspect of C++ talk is actually about: https://akrzemi1.wordpress.com/2012/02/03/value-semantics/

A quick test-run on the pages linked from the hackernews front page:

hackernews svg logo doesn't render

youtube embed on the servo homepage doesn't load

https://github.com/tpope/timl -> reloads/rerenders infinitely, uses 100% of 1 core

https://akrzemi1.wordpress.com/2023/04/23/the-obvious-final-step/ -> hangs while loading the page, uses 100% of 1 core

https://equalitytime.github.io/FlowersForTuring/ -> loads/renders fine

https://github.com/reactos/reactos -> reloads/rerenders infinitely, uses 100% of 1 core

https://dolphin-emu.org/blog/2023/05/27/dolphin-steam-indefinitely-postponed/ -> loads fine but css rendering/placement is off on breadcrumbs and article

https://xcp-ng.org/blog/2023/05/23/new-xen-updates-on-risc-v/ -> very long load then hangs while loading javascript/content.

Not a great batting average - seems like sites need to be purpose built for this or leverage little/no modern javascript libraries for it to render accurately. Servo has been in this state for the last 5 or 6 years since I first discovered it.

I kinda like the way Boost did error_code[1], which got incorporated into C++11[2].

Essentially you got a generic error_code struct which has two members, an int to hold a given error value or zero if there's no error, and a reference to an error category which helps interpret the error value.

Effectively the error category is an interface, so in C terms it would be a reference to an error_category struct filled with function pointers.

There's then some machinery which allows you to compare specific error codes to generic error conditions like "file not found", abstracting away the specifics of the error code.

It's not problem free[3], but I've used this pattern in languages like Pascal and felt it worked well for me.

[1]: https://www.boost.org/doc/libs/1_82_0/libs/system/doc/html/system.html

[2]: https://en.cppreference.com/w/cpp/header/system_error

[3]: https://akrzemi1.wordpress.com/2017/10/14/error-codes-some-clarifications/

When it comes to std::optional, the answer is no. In fact, std::optional<T&> is explicitly forbidden (see here: https://www.fluentcpp.com/2018/10/05/pros-cons-optional-references/)

It is used in some other places though. For instance, std::string implementations typically employ small-string optimization (SSO) which means that there might be a limit on string::size() since some of the bits inside that value are used for different purposes (example: https://akrzemi1.wordpress.com/2014/04/14/common-optimizations/). The "niche" in this case is the realization that strings are unlikely to be exabytes in size, so there is no reason to always store zeros in high bits of _size.