On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
> On 7/25/2014 3:56 PM, David Nadlinger wrote:
>> Let's just get rid of "catch {}" which encourages unsafe code and be done with it.
>
> We need to stop breaking code.

Either change breaks code. There's no evidence to support that catch{} is more commonly used than catch(MyException!true) et al.

On Saturday, 26 July 2014 at 00:10:00 UTC, Jakob Ovrum wrote:
> On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
>> On 7/25/2014 3:56 PM, David Nadlinger wrote:
>>> Let's just get rid of "catch {}" which encourages unsafe code and be done with it.
>>
>> We need to stop breaking code.
>
> Either change breaks code. There's no evidence to support that catch{} is more commonly used than catch(MyException!true) et al.

If you download D-Scanner and run "dscanner --styleCheck -R path/to/code" you can easily tell if the LastCatch syntax is being used. The message you get is "Catching Error or Throwable is almost always a bad idea."

If you find out that some code IS using this old syntax, this tool will fix it automatically: https://gist.github.com/Hackerpilot/5ff6d86f4d22a14a00f3

# Run upgrade
dfix file.d > file.d.fixed
# Check that it worked as expected
meld file.d file.d.fixed
# Overwrite old file
mv file.d.fixed file.d

On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
> On 7/25/2014 3:56 PM, David Nadlinger wrote:
>> Let's just get rid of "catch {}" which encourages unsafe code and be done with it.
>
> We need to stop breaking code.

IMO breaking changes are justified if the changes fix a design flaw in the language or the changes break code that should have never been permitted.

Mike

On 7/25/2014 6:13 PM, Mike wrote:
> IMO breaking changes are justified if the changes fix a design flaw in the
> language or the changes break code that should have never been permitted.

Ironically, today I'm being vehemently argued with for both breaking code and not breaking code.

On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
> On 7/25/2014 6:13 PM, Mike wrote:
>> IMO breaking changes are justified if the changes fix a design flaw in the
>> language or the changes break code that should have never been permitted.
>
> Ironically, today I'm being vehemently argued with for both breaking code and not breaking code.

The fact that you consider this "ironical" means that you have completely missed my point yet again and don't really see the "catch 22" problem with current attitude.

(mentioned argument is here : https://github.com/D-Programming-Language/phobos/pull/2366#issuecomment-50215483)

tl; dr:
- breaking changes are good
- lack of any formal process for breaking changes is bad
- pretending that careful decisions for breakage make big difference is not understanding the problem

On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
> On 7/25/2014 6:13 PM, Mike wrote:
>> IMO breaking changes are justified if the changes fix a design flaw in the
>> language or the changes break code that should have never been permitted.
>
> Ironically, today I'm being vehemently argued with for both breaking code and not breaking code.

Isn't that to be expected in your position?  There will be consequences if a decision is made to not break code, and there will be consequences if a decision is made to break code.

Principles like the 2 I mentioned would help, but Brian's work (std.d.lexer, DScanner, etc...) is showing immense value here in creating a "go tool fix"-like utility [1].  If we (that includes me) would support it and make it a priority, we wouldn't have to take such a hard-line stance on breaking changes.

Mike

[1] http://golang.org/cmd/fix/

On 7/25/2014 6:40 PM, Dicebot wrote:
> tl; dr:
> - breaking changes are good
> - lack of any formal process for breaking changes is bad
> - pretending that careful decisions for breakage make big difference is not
> understanding the problem

I believe we are talking past each other with no understanding.

On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
> Ironically, today I'm being vehemently argued with for both breaking code and not breaking code.

Are the arguments about intentional or unintentional breakages?

On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
> On 7/25/2014 3:56 PM, David Nadlinger wrote:
>> Let's just get rid of "catch {}" which encourages unsafe code and be done with it.
>
> We need to stop breaking code.

At SR Labs, we have no problems at all with that kind of breakage: the LOCS of D code here is growing big, so let's take that kind of adjustment to the language right now, thinking a lot about it, but right now and for a better language.

That kind of braking are in the opinion of my company really a no-issue.

---
Paolo

On Saturday, 26 July 2014 at 10:48:56 UTC, Paolo Invernizzi wrote:
> On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
>> On 7/25/2014 3:56 PM, David Nadlinger wrote:
>>> Let's just get rid of "catch {}" which encourages unsafe code and be done with it.
>>
>> We need to stop breaking code.
>
> At SR Labs, we have no problems at all with that kind of breakage: the LOCS of D code here is growing big, so let's take that kind of adjustment to the language right now, thinking a lot about it, but right now and for a better language.
>
> That kind of braking are in the opinion of my company really a no-issue.

+1

The compiler will detect it, it can suggest what to use instead, and it can even be properly deprecated first.

"Bad" breakage are things that break silently. This, however, is an example of "good" breakage, as it can be detected easily, there is a clear migration path, and it is an overall improvement to the language.