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.
>
> 2. Having optional errors like that leads to unfortunate problems inside generic
> code that tests whether some constructs compile or not.

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.

On 5/23/2013 6:01 PM, Andrei Alexandrescu wrote:
> On 5/23/13 8: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.
>
> I don't understand this. It's change under 100% user control.

Under neither position of the switch is the old runtime behavior maintained. And as I mentioned in another post, the naive (or tired or in a hurry) user just throwing the switch to get his code to compile runs the risk of silent breakage of the runtime behavior.

Furthermore, when we rename a Phobos function, we don't just delete the old name. We go through a period of warnings and deprecations.

I don't believe this change is so needed to justify such an abrupt change. It's a minor improvement.


>> 2. Having optional errors like that leads to unfortunate problems inside
>> generic code that tests whether some constructs compile or not.
>
> The warning has the same problem.

I don't agree that because we have this problem elsewhere, that it should be acceptable to add in more cases.

Walter Bright:

> 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.

Even if such "naive" D programmers exist, maybe it's better to ignore this third point, because they will not be able to program in D for other reasons.

Bye,
bearophile

On Thu, 23 May 2013 21:56:47 -0400, Walter Bright <newshound2@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

On 5/23/2013 7:35 PM, bearophile wrote:
> Walter Bright:
>
>> 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.
>
> Even if such "naive" D programmers exist, maybe it's better to ignore this third
> point, because they will not be able to program in D for other reasons.

s/naive/tired/
s/naive/inahurry/

I'm surprised at you, bearophile!

Walter Bright:

>> Even if such "naive" D programmers exist, maybe it's better to ignore this third
>> point, because they will not be able to program in D for other reasons.
>
> s/naive/tired/
> s/naive/inahurry/
>
> I'm surprised at you, bearophile!

A safe and well designed language is not supposed to save you from using on purpose a switch designed to avoid you some bugs. So I don't agree with this third point of yours.

Bye,
bearophile

On 5/23/2013 7:57 PM, bearophile wrote:
> Walter Bright:
>
>>> Even if such "naive" D programmers exist, maybe it's better to ignore this third
>>> point, because they will not be able to program in D for other reasons.
>>
>> s/naive/tired/
>> s/naive/inahurry/
>>
>> I'm surprised at you, bearophile!
>
> A safe and well designed language is not supposed to save you from using on
> purpose a switch designed to avoid you some bugs. So I don't agree with this
> third point of yours.

I think that is inconsistent with your consistent position that features that are easily misunderstood or misused should have more protection.

So there!

On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
> On Thu, 23 May 2013 21:56:47 -0400, Walter Bright <newshound2@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.

Yeah, that is a problem I hadn't thought of.

> I think the only good solution is to use an error.

Yes, and the error has to be there for long enough to get all the existing code in use to be corrected before the new behavior is enabled.

> A warning is not good
> enough/strong enough.

For now, it is the proper path. The warning is that "change is coming, but you have time to fix it."

> 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.

On Friday, 24 May 2013 at 02:39:26 UTC, Walter Bright wrote:
> On 5/23/2013 7:35 PM, bearophile wrote:
>> Walter Bright:
>>
>>> 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.
>>
>> Even if such "naive" D programmers exist, maybe it's better to ignore this third
>> point, because they will not be able to program in D for other reasons.
>
> s/naive/tired/
> s/naive/inahurry/
>
> I'm surprised at you, bearophile!

I have to second Walter on that one. This does and probably will happen, even with programmer that aren't brain damaged.

On Friday, 24 May 2013 at 03:38:33 UTC, Walter Bright wrote:
> For now, it is the proper path. The warning is that "change is coming, but you have time to fix it."
>

Yes, with an explanation how to fix it, maybe a link to a webpage that explain why the change is made, etc . . .