dmd 2.063 beta 5

[Steven Schveighoffer]

On Thu, 23 May 2013 21:56:47 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 5/23/2013 5:56 PM, Walter Bright wrote:
>> On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
>>> What about making it an error UNLESS you pass a compiler flag.  The  
>>> user will be
>>> informed, and the new behavior (which I find useful) is possible.
>>
>> While that idea has significant merit, I oppose it on the following  
>> grounds:
>>
>> 1. It forces a very abrupt change. We've followed a policy of gradual  
>> change,
>> giving people plenty of time to adapt their codebase. This does not.

What we need is a message that says "what you are doing is wrong, you need  
to put static in front of it."  Since the new behavior never before  
existed, all existing code will be identical if they put static before the  
declaration.

There is no real time needed to adapt their codebase, except for the time  
it takes to find the errors, open a file, type "static " and save it.  No  
thinking is involved.  The error message can say as much.

>>
>> 2. Having optional errors like that leads to unfortunate problems  
>> inside generic
>> code that tests whether some constructs compile or not.

I just realized that there is a large problem with my proposed solution.   
Let's say one library writer has not updated his code to work with the  
latest compiler.  Another library writer starts using the new feature.

Compile them together, and now you have a mish-mash of valid and invalid  
code that either all fails or all compiles based on a switch.

I think the only good solution is to use an error.  A warning is not good  
enough/strong enough.  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.

> 3. Naive users may see their compile fail, see a switch to 'enable' it,  
> and throw the switch. Now it compiles, but fails silently at runtime.  
> This is because the new behavior is quite different from the old, and  
> the code that relies on the old behavior will most likely need to be  
> redone, not just add a switch.

Naive users may do a lot of things to "get it to work."  They may remove  
the const.  I don't think we can guard against naivety.

-Steve