On 7/17/14, 5:57 PM, Brian Schott wrote:
> 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.

I agree. I also internally decided I have a personal mild preference in favor of DIP65, i.e. I'm agreeing with you and disagreeing with Walter. But I'll let it go because:

1. There is clear understanding of the DIP65 on Walter (and my) part.

2. Reasonable people may disagree on the best course of action.

3. Somebody must make a judgment call.

4. It's neither a huge win nor a disaster any way the call goes.

5. In Walter's words - if he and I agreed on everything, we wouldn't be doing our jobs. Same about other community members etc.

6. Part of moving forward is breaking clean with the past.

I think there's better fruit to pluck here. Regarding dfix, I have a suggestion for a simple start - how about rewriting

alias B A;

as

alias A = B;

I've been reading a bunch of Thrift code using the old syntax and the new one is quite easier on the eyes when B is complex.


Andrei

On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
> Walter Bright:
>
> 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.

+1

---
Paolo

On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
> Did you see my response?
>
> I suggested recognizing in the parser:
>
>    ( Identifier )
>
> as a special case, in addition to using Parser::isDeclaration().

I just want to point out that this special case is lacking, and will inevitably cause someone a headache when they try to do something like:

catch(typeof(foo)) {
    ...
}

Which is currently valid (as I'd expect).

On 7/21/2014 3:41 AM, Jakob Ovrum wrote:
> On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
>> Did you see my response?
>>
>> I suggested recognizing in the parser:
>>
>>    ( Identifier )
>>
>> as a special case, in addition to using Parser::isDeclaration().
>
> I just want to point out that this special case is lacking, and will inevitably
> cause someone a headache when they try to do something like:
>
> catch(typeof(foo)) {
>      ...
> }
>
> Which is currently valid (as I'd expect).

That can be special cased, too.

On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
> That can be special cased, too.

Seriously? Where does it end?

catch(MyTemplatedException!true) {
}

Parsing this as a proper type without a trailing identifier is a nice feature that a lot of people use, unlike the ghastly catch {} feature that nobody uses and should be considered harmful. Whether we constrain the former or kill the latter, they're both breaking changes. So why are we favouring the *bad* one?

On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
> On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
>> That can be special cased, too.
>
> Seriously? Where does it end?
>
> catch(MyTemplatedException!true) {
> }

That one can't be special cased in the parser.


> Parsing this as a proper type without a trailing identifier is a nice feature
> that a lot of people use, unlike the ghastly catch {} feature that nobody uses
> and should be considered harmful. Whether we constrain the former or kill the
> latter, they're both breaking changes. So why are we favouring the *bad* one?

Because it breaks the least amount of code.

Walter Bright:

> Because it breaks the least amount of code.

This is not a good idea. What about the future code that will be buggy/wrong?

Bye,
bearophile

On Friday, 25 July 2014 at 21:34:22 UTC, Walter Bright wrote:
> On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
>> On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
>>> That can be special cased, too.
>>
>> Seriously? Where does it end?
>>
>> catch(MyTemplatedException!true) {
>> }
>
> That one can't be special cased in the parser.
>
>
>> Parsing this as a proper type without a trailing identifier is a nice feature
>> that a lot of people use, unlike the ghastly catch {} feature that nobody uses
>> and should be considered harmful. Whether we constrain the former or kill the
>> latter, they're both breaking changes. So why are we favouring the *bad* one?
>
> Because it breaks the least amount of code.

I hope you are running head first into a usability disaster here. From a user's perspective, MyTemplatedException!true is a type just like MyException is and there is no reason why it should work differently. Remember built-in types and alias parameters?

Let's just get rid of "catch {}" which encourages unsafe code and be done with it.

David

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.

Walter Bright:

> We need to stop breaking code.

We also have a responsibility for the bad D code yet to be written :-)

Bye,
bearophile