On 5/23/2013 11:17 PM, Walter Bright wrote:
On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:
On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
<[email protected]>
wrote:
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
This is one change where ALL code broken by this change
is fixable with a simple solution, and at some point, people will
have to deal
with this.
Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the
warning.
If they aren't in the mood to change their code, they don't have to
upgrade to
the latest compiler.
Q: Why do we bother with the whole warning and deprecation thing anyway?
A: Because forcing people to conform to our schedule with no warning is
a bit presumptuous. Someone writing a library, for example, has to be up
to date, and anyone using that library, for another, has to deal with it
if it fails to compile. If your code is built from multiple blobs from
various places, it is unreasonable to expect them to all instantly and
simultaneously upgrade.
I would argue the language should be designed with the ability to easily
add keywords without breaking things. I would expect a simple
implementation to be that each source file needs to be marked up with a
version of the compiler it is designed for, and the compiler could tell
you that A) you are using what is now a keywords B) compile the code
correctly anyway.
The lack of this kind of feature is why c++11's new null type is named
nullptr, and not null, and why pure virtuals are declared with '=0'
instead of a keyword. Arguably c++11's range based for loops are also
designed with this constraint (avoid adding a keyword), but is a not
ugly like =0 pure virtuals :)
