[olliej]

But that change is by definition not backwards compatible - neither ABI nor source level.

Using an ifdef to maintain source level compatibility doesn't work as two pieces of code will see the same function using different ABIs.

That said I agree entirely - the conflation of array and pointer is the biggest flaw, it's what "necessitated" the null termination error that people are so fond of calling the biggest mistake.

[WalterBright]

Sorry, I meant it does not break existing code.

[olliej]

Fair enough - but I also get the point that it's absurd that "modern" "safe" C++ is invariably more obnoxious and verbose than the unsafe version.

Then when new syntax _is_ added, there is no attempt to fix anything. My favorite example is the iterator syntax:

    for (thing: things) ...

Being defined as equivalent to

    for (iter = things.begin(), end = things.end(); iter != end; ++iter) { thing = *iter; ... }

Which is great because it makes any kind of range checking or reallocation safe enumeration much slower. All just to allow the spec to avoid making changes to existing "idiomatic" begin()/end() based code.

So prior to this syntax I had made the WebKit Vector class perform bounds checking on any indexed access, in all build modes. So enumeration was generally indexed, because begin()/end() are atrocious, and that meant that enumeration was both bounds and reallocation safe. But then the enumeration syntax came along, specifically in terms of begin()/end() - and I was never able to make an iterator that could have the required semantics that didn't simply shit the perf bed.

So now you have a new "modern" C++ iterator that is strictly less safe than the old form of iteration, and for which a safe and secure iterator is intrinsically hard to optimize due to the semantics of the rest of the language. Hurrah.

[WalterBright]

For D it looks like:

    for (thing; things) { ... }

which is rewritten as:

    for (auto r = things; !r.empty; r.popFront) { auto thing = r.front; ... }