
Deprecating Raw Pointers in C++20 - joebaf
http://www.bfilipek.com/2018/04/deprecating-pointers.html#
======
titzer
It's an April fool's day joke in the best tradition: a parody almost
indistinguishable from truth. C++ has jumped the shark.

Prima facie C was created as a portable assembly language that very nearly
reflected the underlying hardware. Then C++ added new abstraction mechanisms
on top of C, that were at first totally orthogonal: just classes and
templates. One could still use all of C to get at the raw machine (raw
pointers and peeking/poking). Then as abstraction envy grew to overcome C++,
as it does every active language in time, C++ drifted farther and farther from
its system-y roots. Fine.

But in my day job, the only real reason to use C++ is because it's the only
realistic choice as a systems language. I need to peek and poke memory, jump
to raw machine code I've generated at runtime. This doesn't make me better or
worse, it's just my use case (a virtual machine). As C++ becomes less and less
capable of doing these low-level unsafe things (because too many people caused
too much damage attempting this), and adds more ceremony to the old ways of
peeking and poking memory, it becomes less useful to me. Who is it useful for?

I'd argue that C++ has drifted off into some fantasy world where it believes
it's a beautiful language full of nice, solid abstractions. But IMO it isn't--
probably can't be--as all the abstractions break down, leaving us in the
lurch, with neither good systems programming support nor good application-
level abstraction.

~~~
Mindless2112
> _C++ has drifted off into some fantasy world_

I like what E. W. Dijkstra had to say in "The Humble Programmer":

> _Finally, although the subject is not a pleasant one, I must mention C++, a
> programming language for which the defining documentation is of a
> frightening size and complexity. Using C++ must be like flying a plane with
> 7000 buttons, switches and handles to manipulate in the cockpit. I
> absolutely fail to see how we can keep our growing programs firmly within
> our intellectual grip when by its sheer baroqueness the programming language
> —our basic tool, mind you!— already escapes our intellectual control. And if
> I have to describe the influence C++ can have on its users, the closest
> metaphor that comes to my mind is that of a drug. I remember from a
> symposium on higher level programming language a lecture given in defense of
> C++ by a man who described himself as one of its devoted users. But within a
> one-hour lecture in praise of C++. he managed to ask for the addition of
> about fifty new “features”, little supposing that the main source of his
> problems could very well be that it contained already far too many
> “features”. The speaker displayed all the depressing symptoms of addiction,
> reduced as he was to the state of mental stagnation in which he could only
> ask for more, more, more... When FORTRAN has been called an infantile
> disorder, full C++, with its growth characteristics of a dangerous tumor,
> could turn out to be a fatal disease._

April fool's. He actually said that about PL/1 [1].

[1]
[https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...](https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)

~~~
titzer
Great quote, thanks!

------
mbel
The fact that this headline cannot be distinguished from April Fools joke by
other commenters seems to say a lot about the direction in which C++ standard
committee is heading.

~~~
codeflo
It’s not like the idea is completely crazy; pointer misuse is a big source of
all kinds of problems, Rust shows how much can be done without constantly
using raw pointers, and what are the C++ Core Guidelines if not an effort in
exactly this direction?

I finally “got” that this is a joke when they discussed the future
alternatives:

> For copyable and assignable references you can use std::reference_wrapper.
> ([http://en.cppreference.com/w/cpp/utility/functional/referenc...](http://en.cppreference.com/w/cpp/utility/functional/reference_wrapper))

and thought, ha ha, an “assignable reference” instead of a “pointer”, that’s
obviously completely different. :) What a subtle joke!

Only now I see that reference_wrapper is apparently completely real and exists
since C++11. Why does this even exist? My head hurts from banging it against
the desk.

~~~
_o_
1\. April joke :)

The point of c/c++ in comparision to other languages is that you can do
anything and having a huge toolbox for that. Pointers are excelent
sledgehammer. You can be perfectly fine with not using them but c++ _need_ to
have them. The pointers are not source of the problem, the developer is.
That's why languages like java are prospering, it prevent incompetent people
making stupid mistakes and that is fine. But some people need and want freedom
that c++ offers.

~~~
pjmlp
You can have languages that prevent people making stupid mistakes and still
offer full control over the hardware, that is what languages like Modula-2 and
Ada offer.

~~~
evincarofautumn
Yeah, also Rust and ATS. A good systems language just needs to _allow_ low-
level and unsafe operations; nowadays the industry is warming up to the idea
that such operations shouldn’t be available _by default_. Having to opt in
with a machine-checked “unsafe” annotation means you have an explicit
indication in the code of everywhere things _could_ go wrong with type/memory
safety, which means when something does go wrong, you know it _must_ be caused
by one of those unsafe regions.

------
cesarb
Having started using the Internet in the 90's, and thus still remembering
Geocities-era websites, I loved that they did this as a webring
([https://en.wikipedia.org/wiki/Webring](https://en.wikipedia.org/wiki/Webring)):
each blog post has a link to the next one, making a singly-linked circular
list.

Starting with this one, we have:

\- [http://www.bfilipek.com/2018/04/deprecating-
pointers.html](http://www.bfilipek.com/2018/04/deprecating-pointers.html)

\- [http://www.modernescpp.com/index.php/no-new-
new](http://www.modernescpp.com/index.php/no-new-new)

\- [https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-
have...](https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-
pointers/)

\- [https://blog.tartanllama.xyz/no-
pointers/](https://blog.tartanllama.xyz/no-pointers/)

\- [https://arne-mertz.de/2018/04/raw-pointers-are-gone/](https://arne-
mertz.de/2018/04/raw-pointers-are-gone/)

And it circles back to this one.

------
rosshemsley
This could be a joke. Or not.

It is very much in keeping with the current direction of C++, which appears to
be:

"Oh no, C++ cannot keep pace with modern systems languages, let's repair it by
whatever means possible"

Their heart is in the right place, but perhaps this accelerated process of
mutating the language will ultimately be what kills it.

Personally, after having deep expertise in C++(11/14) I jumped ship to Go and
will _never_ look back...

~~~
gmueckl
There is nothing in C++ 11 and later that is forced on you. Everything that
was added is optional. For personal projects I depend on some alternate
implementations for things that are now in the STL because these not complete
enough for my needs.

~~~
pmorici
That only works if you are working alone. In a real world team environment you
can’t always enforce your preferences on your teammates

~~~
gmueckl
I did not wrote these things for fun. I had a real need for each one. The STL
is fine for the average case, but it is also limited. I hit these limitations.

------
berkut
I hope this is a joke: the std::weak_ptr / std::shared_ptr combo (only non-
reference alternative I can think of other than std::optional) can have pretty
bad performance implications due to ref-counting atomics in multi-threaded
scenarios...

For the use-case of optional pointers that don't have any ownership (and can
possibly be updated mid-lifetime) and have a guaranteed external lifetime,
what's the alternative?

Are there any other ways of doing this that are guaranteed to have no
performance (time or memory) overhead in modern C++ (relying on by-value move
semantics isn't ideal) ?

Also, what about std:atomic (CAS) raw pointers - for high-performance /
lockless stuff, they can be critical...

~~~
mehwoot
_For the use-case of optional pointers that don 't have any ownership (and can
possibly be updated mid-lifetime) and have a guaranteed external lifetime_

Those three things seem like a pretty rare co-occurrence, if something has no
ownership how can it have guaranteed external lifetime without being reference
counted? I guess it's possible but in any scenario I come up with reference
counting seems an easier way to do it.

------
ChrisSD
I guess a serious point is that modern C++ does "deprecate" raw pointers in
the sense that their use is discouraged outside of interfacing with external
libraries or old C++ code.

But that's more the realm of linters than compiler warnings.

~~~
xwvvvvwx
I'm not sure that's quite true. Raw pointers are fine if you need a nullable
non-owning reference type.

------
jhanschoo
This sounds to me like an April Fools joke, but the linked article on new new
written on 26 March makes it sound like it's not...

~~~
shakna
They link back from there to a April 1st post, however.

> Additionally, I refer to the post C++ Will no Longer Have Pointers by Fluent
> C++

Following the trail of references just loops around a half dozen April 1st
posts.

With that, and nothing on the drafts [0], that I can see, I'm leaning towards
joke.

[0] [https://github.com/cplusplus/draft](https://github.com/cplusplus/draft)

------
MichaelMoser123
In other news: Bjarne Stroustrup hast been fired by the C++ language
committee, as one data member declared "we are sick and tired of this backard
compatibility with C mantra, we all want to party like Rust!". Today
everything is possible...

------
alephr
"The C++ Standard moves at a fast pace."

Too obvious.

------
enitihas
Can someone with more knowledge about c++ standard comment whether this is for
real or it is an April Fools joke. Wouldn't this be an enormous change and
probably break the language?

~~~
mbel
It seems to be a joke, they would have serious problem with backward
compatibility with "this" pointer. Also it would limit the use cases for the
language, unless they would introduce something like std::raw_ptr, which to be
honest would be quite funny.

~~~
evincarofautumn
Honestly this wouldn’t be a bad idea for consistency, teaching, and template
programming purposes:

    
    
        namespace std {
            template<typename T>
            using raw_ptr = T*;
        }
    
        // mutable pointer to const value
        int const *a_old;
        std::raw_ptr<int const> a_new;
        std::raw_ptr<const int> a_new_var;
    
        // const pointer to mutable value
        int *const b_old;
        std::raw_ptr<int> const b_new;
        const std::raw_ptr<int> b_new_var;
    
        // const pointer to const value
        int const *const c_old;
        std::raw_ptr<int const> const c_new;
        const std::raw_ptr<const int> c_new_var;
    

I’ve actually used this before to parameterise a struct/class with an
ownership policy, for example:

    
    
        template<template<typename T, typename...> class P>
        struct Wrapper {
            P<int> value;
        };
    

Now Wrapper<std::raw_ptr> is a non-owning Wrapper, while
Wrapper<std::unique_ptr> is an owning one.

------
sus_007
Another blogger wrote about this : [https://www.fluentcpp.com/2018/04/01/cpp-
will-no-longer-have...](https://www.fluentcpp.com/2018/04/01/cpp-will-no-
longer-have-pointers/)

Is this actually a joke ?

~~~
tomsmeding
You can follow the links to more details, which goes to a different blog post.
Each has another blog post as a source, and eventually comes back in a circle
to the original one.

This is most definitely an April Fool's joke.

------
neals
I've never done any real development with a language that uses pointers. So
noob question: why would one use a pointer over passing a variable? (those are
the two flavors right?)

~~~
em3rgent0rdr
When passing a pointer, if you want the resulting state of the variable, the
function doesn't need to return a value. Also if the variable is a large
object, then passing just a pointer to it saves time spent copying the object.

~~~
Koshkin
I am sure parent meant "passing by reference". (In Oberon, for example, this
is indicated by the VAR keyword.)

------
2aa07e2
Obvious joke is obvious. I looked at the date immediately after reading the
title. Now, if that was to be discussed for C++23, that could indeed be
plausible... yet still unlikely.

------
Koshkin
On a more serious note, raw pointers can be seen as _practically_ deprecated
in C++ since its inception (at least inside code that is not considered
library or low-level).

------
erAck
Eventually C++ will be a well thought out standard.

------
jng
Hacker News also doing April Fools now...

------
tomsmeding
If you click on the "more details" link, you end up on a different blog post,
saying some of the same things. Looks like it has a reference.

But then that post also has a link to a source, which is another blog post,
which links to another, which via a few more links back to this one.

We have citogenesis[1] in actual action.

[1] [https://xkcd.com/978/](https://xkcd.com/978/)

------
bumblebritches5
so tldr, the C haters have won in the process of rubyizing C++ for webdevs who
literally could not care less about a language that they have absolutely no
use for...

I'm glad I decided against moving to C++

~~~
chris_wot
Look at the date on the article...

