I made a wrapper to support this: https://gist.github.com/ayosec/816ccba7a75aba5336db0fe0b9791...

Apparently not. You can create a test.html file with the following content:

    <script>
      fetch(".").then(r => console.log(r));
      fetch("/").then(r => console.log(r));
    </script>

The console show errors when these URLs are loaded:

    TypeError: NetworkError when attempting to fetch resource. test.html:2:1

How is that different to this?

    if (my_pointer != NULL)
        do_stuff(*my_pointer)

Native pointers do a bunch of different things depending on the context. In contrast, optional has clear semantics.

For instance, the ++ operator doesn't work for std::optional. For a native pointer, you just have to know (how?) not to use it.

In terms of generated coded, it is exactly the same. But that's not the point of optional types.

The point of optional types is to force you to write checks for undefined values, otherwise your code will not compile at all. In the old-fashioned style of your example, you might forget to check for the possibility of a null pointer/otherwise undefined value, and use it as if it were valid.

But the whole genesis for this comment chain is that you can make exactly the same mistake with std::optional.

Only if you deliberately unwrap the optional, which means you either don’t know what you are doing (in which case no programming language feature will be able to save you), or that you’ve considered your options and decided you want to enter the block knowing some variable can be undefined.

IMO, that’s not the same as not having optionals at all, and writing unconditional blocks left and right that may or may not operate on undefined values. It super easy to just dereference any pointer you got back from some function call in C++, without paying attention. Optionals force you to either skip the blocks, or think about how to write them to handle undefineds. Also, it’s ‘code as documentation’ in some sense, which I’m a big proponent of.

> Only if you deliberately unwrap the optional

"Deliberately unwrap the optional" is the exact same thing as "deliberately unwrap the pointer", you just deref' it and it's UB if the optional / pointer is empty.

C++'s std::optional is not a safety feature (it's no safer than using a unique_ptr or raw pointer), it's an optimisation device: if you put a value in an std::optional you don't have to heap allocate it.

> It super easy to just dereference any pointer you got back from some function call in C++, without paying attention.

And optionals work the exact same way. There's no difference, they don't warn you and they don't require using a specific API like `value_unchecked()`. You just deref' the optional to get the internal value, with the same effects as doing so on any other pointer.

sponge[1] is very useful in this scenario. The output file is written only when the `thing | thing | thing` finishes successfully.

[1]: https://linux.die.net/man/1/sponge

> I'd be willing to bet your "small number" of white listed websites is actually a lot more than you think. Turning off Javascript breaks a ton of sites, IME.

My experience is the opposite.

I used NoScript for almost 8 years, and then switched to uMatrix one year ago.

I don't need to enable JavaScript in most sites. And, if I need it, only enable some parts of the page. Most websites are much faster with this.

> It's a new stand-alone HTTP server.

Are you going to publish more info about that HTTP server? Like the technology used to write it.

Yeah, I'll probably write that up at some point.

For now, here's the source code for the HTTP implementation. :)

https://github.com/capnproto/capnproto/blob/master/c++/src/k...

https://github.com/capnproto/capnproto/blob/master/c++/src/k...

That's from the KJ C++ toolkit library, which is part of the Cap'n Proto project, which is my own work that predates my time at Cloudflare. We're using this in the Workers engine and updating the code as needed.

Yes, I know, NIH syndrome. But it has been pretty handy to be able to jump in and make changes to the underlying HTTP code whenever we need to.

I hope to spend some time writing better docs for KJ, then write a blog post all about it.

The only major dependencies of the core Workers runtime are V8, KJ, and BoringSSL.

> Even serde has `#[serde(rename = "name")]` for this purpose.

You can use `#[serde(rename_all = "camelCase")]`[1] in the struct to apply the fix to all fields.

[1]: https://serde.rs/container-attrs.html#serderenameall--

Out of curiosity, what version of c++filt are you using?

I tried with 2.27.51 (Debian), and it works:

    mozilla::EnableIf<mozilla::IsSame<decltype ((((JS::GCVector<jsid, 0ul, js::TempAllocPolicy>*)((decltype(nullptr))0))->begin)()), decltype ((((JS::GCVector<jsid, 0ul, js::TempAllocPolicy>*)((decltype(nullptr))0))->end)())>::value, void>::Type js::CompartmentChecker::check<JS::GCVector<jsid, 0ul, js::TempAllocPolicy> >(JS::GCVector<jsid, 0ul, js::TempAllocPolicy> const&)

2.26.1-1.fc25 from Fedora 25

> Why do mobile browsers not provide the option to disable this bug?

In Firefox, you can set browser.ui.zoom.force-user-scalable to true.

Unfortunately, if have JavaScript enabled, some pages are still able to disable the zoom.