On Thursday, 17 July 2014 at 22:07:41 UTC, Brian Schott wrote:
> On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
>> Writing such a tool is a major operation.
>
> // I disagree.

Posted a bit too soon. Should look more like this..

		case tok!"catch":
			size_t j = i + 1;
			while (j < tokens.length && (tokens[j] == tok!"whitespace" || tokens[j] == tok!"comment"))
				j++;
			if (j < tokens.length && tokens[j].type != tok!"(")
			{

The lexer code is here: https://github.com/Hackerpilot/libdparse

On 7/17/2014 3:07 PM, Brian Schott wrote:
> On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
>> Writing such a tool is a major operation.
>
> // I disagree.
> [...]

I'm impressed. I withdraw that comment.

On 7/17/2014 3:17 PM, Walter Bright wrote:
> On 7/17/2014 3:07 PM, Brian Schott wrote:
>> On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
>>> Writing such a tool is a major operation.
>>
>> // I disagree.
>  > [...]
>
> I'm impressed. I withdraw that comment.
>

BTW, it's not perfect because of token string literals and string mixins, but it's good enough.

Walter Bright:

> BTW, it's not perfect because of token string literals and string mixins, but it's good enough.

In general the creation of a tool like Go fix (http://golang.org/cmd/fix/ ) for D could change a little the trade-offs regarding the tiny Phobos/D breaking changes.

Bye,
bearophile

On Thu, Jul 17, 2014 at 11:39:56PM +0000, bearophile via Digitalmars-d wrote:
> Walter Bright:
> 
> >BTW, it's not perfect because of token string literals and string mixins, but it's good enough.
> 
> In general the creation of a tool like Go fix (http://golang.org/cmd/fix/ ) for D could change a little the trade-offs regarding the tiny Phobos/D breaking changes.
[...]

This got me thinking, if dmd came with a -fix option, perhaps, that will either automatically fix your code or print out a list of suggested fixes, then perhaps breaking changes might be more palatable?

For example:

1) I install dmd 2.065, and write my project according to it.

2) I see that 2.066 has been released, so I download and install it.

3) When I try to compile my project, it tells me:

	yourcode.d(123): deprecated syntax, please run with -fix to
	automatically correct it, or -d to compile according to 2.065
	syntax.

4) I don't have time to verify the fixes at this time, so I run dmd with -d to get my product out the door.

5) 2 weeks later, I have some free time, so I run dmd -fix on my code to upgrade to the new syntax. Then I review the changes and approve them. Or, alternatively, I run dmd -fix -diffonly to see what the compiler's suggestions of changes are, and modify my code by hand accordingly.

6) Now I can compile with "native" 2.066 mode.


Once this pattern becomes established, it can be simplified into just:

1) Install 2.065. Compile my project.

2) Upgrade to 2.066.

3) Run dmd -fix (upgrade syntax after each compiler upgrade).

4) Compile my project as before.

5) ... ditto


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher

On 7/17/14, 2:51 PM, bearophile wrote:
> Walter Bright:
>
>> We need to STOP breaking existing code.
>
> This is a small example case where I suggest to break hypothetical
> existing code:
> https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265
>
>
> The fear of breaking code should NOT freeze our brains in terror. For
> each sigh of broken code could exist one thousand sighs caused by broken
> designs that will keep causing troubles forever.

Doesn't seem like terror to me. Thing is there's got to be a win there for the breakage to be justified. -- Andrei

On 7/17/14, 3:01 PM, Dicebot wrote:
> On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
>> Walter Bright:
>>
>>> We need to STOP breaking existing code.
>>
>> This is a small example case where I suggest to break hypothetical
>> existing code:
>> https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265
>>
>>
>> The fear of breaking code should NOT freeze our brains in terror. For
>> each sigh of broken code could exist one thousand sighs caused by
>> broken designs that will keep causing troubles forever.
>
> Your proposal there is much much worse than one to deprecate `catch()` -
> it may result in silent change of behavior

That would be serious. What code would change behavior with Walter's proposal? -- Andrei

On 7/17/14, 3:13 PM, Brian Schott wrote:
> On Thursday, 17 July 2014 at 22:07:41 UTC, Brian Schott wrote:
>> On Thursday, 17 July 2014 at 21:44:02 UTC, Walter Bright wrote:
>>> Writing such a tool is a major operation.
>>
>> // I disagree.
>
> Posted a bit too soon. Should look more like this..
>
>          case tok!"catch":
>              size_t j = i + 1;
>              while (j < tokens.length && (tokens[j] == tok!"whitespace"
> || tokens[j] == tok!"comment"))
>                  j++;
>              if (j < tokens.length && tokens[j].type != tok!"(")
>              {
>
> The lexer code is here: https://github.com/Hackerpilot/libdparse

Whatever comes of DIP65, it shouldn't influence our determination to define such a tool. -- Andrei

On Friday, 18 July 2014 at 00:48:38 UTC, Andrei Alexandrescu wrote:
> That would be serious. What code would change behavior with Walter's proposal? -- Andrei

That was an answer to bearophile, not Walter, false alarm ;)

On Friday, 18 July 2014 at 00:50:33 UTC, Andrei Alexandrescu wrote:
> Whatever comes of DIP65, it shouldn't influence our determination to define such a tool. -- Andrei

I started with proposing this syntax change because it is the easiest thing I can think of to fix automatically. Dfix should start small and it doesn't get smaller than this.