Hacker News Reader

Comment by codeflo | Hacker News Reader

    template <typename T>
    struct optional {
      // One version of value which works for everything
      template <class Self>
      constexpr auto&& value(this Self&& self) {
        if (self.has_value()) {
            return std::forward<Self>(self).m_value;
        }
        throw bad_optional_access();
      }

The fact that I can read this and don't even find it that terrible is proof that C++ has permanently damaged my brain.

View on HN

Why? It’s hard or impossible to even express something like this in most languages, and deducing this makes it more compact and clear.

i've been using c++ since the mid 80s (cfront), and it is my favourite language, but i sometimes have bad thoughts about modern c++ syntax - if double ampersands (logic op excepted) are now with us, can triple ampersands be far behind? i wish we could maybe introduce a few new keywords.

mind you, i feel much the same regarding rust syntax.

Triple ampersand already came up somewhere. I don't quite remember in what context but iirc they simplify to normal lvalue refs (at least in that context).

I think you're talking about perfect forwarding and reference collapsing rules [1, 2], introduced in C++11, but that is a bit different thing occurring only in a template instantiation context. Normally, you wouldn't see triple ampersands in sane C++ code, afaik.

[1] http://thbecker.net/articles/rvalue_references/section_08.ht...

[2] https://en.cppreference.com/w/cpp/language/reference

One question I have about the double ampersands when applied to types is: do they represent two different concepts depending on usage? Like I know that they indicate an rvalue reference, but they're also used for perfect forwarding. Those two concepts don't seem inherently connected to me, so the double ampersands appear to be overloaded here. Is that the case or is there some relation I'm missing?

I think of the rvalue reference as talking about the object itself rather than how you get to it (i.e. the actual bytes on a chip someplace as opposed to its address or a copy of an object). Hence moving, perfect forwarding, etc are roughly-synonymous ways to think of managing that object, maybe just looking at the same semantics from different angles.

This is just a conceptualisation, of course (rvalue definition is a little more subtle), but for me as a Lisp programmer it seems natural and intuitive. If you come from a different background or perspective I understand that it can seem weird — again, most languages are not as expressive.

The low level nature that is fundamental to C++, even when you are programming at a very high level, which you now conveniently can, is a consequence of it working hard to be a zero-cost-abstraction systems programming language, leads to issues like this one, or to some odd consequences of move constructors.

There are alternative points in the solution space. Compare it to go, which explicitly papers over some of these trade offs, making an opinionated choice instead, and being willing to embrace reduced expressive power (so there are some things you just can’t write in it). I don’t like go myself, but that doesn’t mean people who choose it are fools.

Yes. It normally indicates an rvalue reference, but in the context of deducing types (for example, in template instantiation or auto deduction), it can mean a forwarding reference and has a rather special meaning.[1][2]

[1]: https://eli.thegreenplace.net/2014/perfect-forwarding-and-un... [2]: https://en.cppreference.com/w/cpp/language/reference#Forward...

Every keyword (unlike a symbol in std::) risks colliding with existing code, so reuse is greatly preferred.

Yes, it is, to be diplomatic, highly imperfect, but working to avoid breaking existing code is one reason C++ is so successful.

yeah, i know all about that. but still, i think that c++ (and c, for that matter) could do with more alphabetic keywords. and after all, the original language introduced quite a few!

Wouldn't C's approach with macros help? E.g. the language defines a keyword like _Foobar which is supposed to be used via #include <foobar> that defines a "#define foobar _Foobar" macro, thus avoiding any collisions with existing code and any new code that needs to use the new keyword can opt-in and deal with any collisions (since the code will be modified anyway).

stroustrup's ambition for c++ was to get rid of the preprocessor (unfufilled, sadly). also, defining a name such as _Foobar does not avoid a clash with existing code - names like that are reserved in c++ and may be used by the standard library.

The standard library is at least under the control of the people implementing the standard, which is much smaller breakage (ie can be fixed at the time of implementing support for the keyword) than breaking a random users code.

The standard could go as far as to say what <foobar> should provide and then leave it up to the implementation what the actual non-aliased keyword actually is: maybe it’s _Foobar or maybe it’s something else, the end user won’t know because you just use foobar after including <foobar>

I would not like this at all.

Keyword are part of the compiler; libraries (header files, modules, what have you) are not.

It’s perfectly legit to write and use a program that doesn’t use anything in std::

I know this is a bit of an “angels on the head of a pin” position to take.

Still, the code quadruplication it replaces is no less gaga.

Possibly, I mean I can't even figure out where the first brace closes.

Reply on news.ycombinator.com