C's definition would be incredibly unpleasant to use with no implicit conversions from void * . If you had to write things like int * x = (int *)NULL I'm pretty sure everyone would just use 0.

I'm not convinced that the explosion of specialized types benefits anyone but language lawyers. Some of us actually have work to do, and NULL should mean NULL.

Using '0' for null pointers as mpyne suggests is less desirable because it robs the reader of context ("Is this a pointer being compared to 0, or a numeric type?") That could be worked around with Hungarian notation, but some would argue that the cure is worse than the disease.

But before nullptr, NULL didn't portably mean "a null pointer". It meant "0", just as if you'd typed in "0" rather than "NULL". The language doesn't really give the library writer much choice in the matter! (Defining NULL as "((void *)0)" would at least give it an inherently pointer type, but it would be terribly inconvenient to use.)

This is the whole reason for nullptr in the first place.

Right, I'm saying that as long as they were going to redefine NULL as part of the C++ standard anyway, they should have redefined it as ((void *) 0). That would be portable, at the expense of breaking code that used NULL in integer comparisons.

C++ doesn't have an automatic conversion from void* to T* so having NULL as ((void*)0) wouldn't have worked.

True, but again, the whole problem is all of these weird, random changes and exceptions that only a small subset of programmers can keep in their heads. If you're going to go down that path, you should pick safe weird, random changes and exceptions.

In this case, they should have turned NULL into a first-class keyword that would parse as an invalid pointer of any given type, and called it "done." In the original C spec NULL wasn't supposed to be a pointer at all -- it was just a more polite way to write "zero." As endless Internet debates have shown, it turns out that it would have been better to reserve it for use in pointer expressions.

Turning a macro defined in probably hundreds of header files into a keyword would be a very bad idea for backward compatibility. It would have been nice if C had reserved it for use as a pointer and C++ had been coded from the beginning to allow NULL to be defined to any pointer type, but that wasn't how it ended up.

But what library vendors can do now is to simply

    #ifdef __cplusplus
    #if /* version check for C++11 */
    #undef NULL
    #define NULL nullptr
    #endif
    #endif

And that way there's less stuff to memorize, but still requires that the code itself has to opt-in, instead of the language having to figure out what insanity NULL may have been defined to.