On 07/25/2014 11:34 PM, 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.

I'd suggest to just special case the general thing, or not add any special cases at all.

catch(Type)
     ^~~~~~

I.e. use lookahead to determine whether something that looks like a type follows a '(' token and is itself followed by a ')' token.

On Monday, 28 July 2014 at 19:12:49 UTC, Timon Gehr wrote:
> I'd suggest to just special case the general thing, or not add any special cases at all.
>
> catch(Type)
>      ^~~~~~
>
> I.e. use lookahead to determine whether something that looks like a type follows a '(' token and is itself followed by a ')' token.

This doesn't help.

catch (Type).functionName() is valid both as

LastCatch
 PostfixExpression
  PostfixExpression
   PostfixExpression
    PrimaryExpression
     '(' Type ')'
   '.' identifier
  '(' ')'

And as

Catch
 '(' Type ')'
 PrimaryExpression
  '.'
  PostfixExpression
   PrimaryExpression
    'functionName'
   '(' ')'

On 07/28/2014 09:32 PM, Brian Schott wrote:
> On Monday, 28 July 2014 at 19:12:49 UTC, Timon Gehr wrote:
>> I'd suggest to just special case the general thing, or not add any
>> special cases at all.
>>
>> catch(Type)
>>      ^~~~~~
>>
>> I.e. use lookahead to determine whether something that looks like a
>> type follows a '(' token and is itself followed by a ')' token.
>
> This doesn't help.
> ...

Depends on what outcome one is after.

> catch (Type).functionName() is valid both as
>
> LastCatch
>   PostfixExpression
>    PostfixExpression
>     PostfixExpression
>      PrimaryExpression
>       '(' Type ')'
>     '.' identifier
>    '(' ')'
>
> And as
>
> Catch
>   '(' Type ')'
>   PrimaryExpression
>    '.'
>    PostfixExpression
>     PrimaryExpression
>      'functionName'
>     '(' ')'
>

Obviously, hence the alternative suggestion to not add any special cases (and then the most sensible way out seems to be to just retire the catch-all syntax).

(But as you're likely to know, there are some of those cases already (if less severe):

foreach(i;0..n){
    // ...
}
(&x).foo();

The above is grammatically ambiguous, but DMD parses it as two distinct statements using an ad-hoc disambiguation rule.

try{
   // ...
}catch(Exception e){
    return e;
}
(new Exception("hi")).msg.writeln;

Similarly. In contrast to above, the alternative parsing might actually pass the type checker.)

On Monday, 28 July 2014 at 20:14:24 UTC, Timon Gehr wrote:
> foreach(i;0..n){
>     // ...
> }
> (&x).foo();
>
> try{
>    // ...
> }catch(Exception e){
>     return e;
> }
> (new Exception("hi")).msg.writeln;

I don't see how these are ambiguous.

On 07/28/2014 10:23 PM, Brian Schott wrote:
> On Monday, 28 July 2014 at 20:14:24 UTC, Timon Gehr wrote:
>> foreach(i;0..n){
>>     // ...
>> }
>> (&x).foo();
>>
>> try{
>>    // ...
>> }catch(Exception e){
>>     return e;
>> }
>> (new Exception("hi")).msg.writeln;
>
> I don't see how these are ambiguous.

Both are ambiguous for the same reason. They are ambiguous because there exist delegate/function literals of the form

enum e={ return 2; }();
       ^~~~~~~~~~~~~
       an expression

The following program demonstrates how to disambiguate the code such that it is parsed in the alternative way:

import std.stdio;

void bar(){
    foreach(x;0..10)(){
        // ...
    }
    (&x).foo();
}

void main(){
    Exception e(){
        try{
            // ...
            throw new Exception("foo");
        }catch delegate(Exception e){
            return e;
        }(new Exception("hi")).msg.writeln;

        return null;
    }
    e();
}

On Monday, 28 July 2014 at 20:51:55 UTC, Timon Gehr wrote:
> Both are ambiguous for the same reason. They are ambiguous because there exist delegate/function literals of the form
>
> enum e={ return 2; }();
>        ^~~~~~~~~~~~~
>        an expression

ForeachStatement:
    ... NoScopeNonEmptyStatement

...

PrimaryExpression:
    FunctionLiteral

FunctionLiteral:
    FunctionBody

FunctionBody:
    BlockStatement

I had forgotten about this particular WTF.

Walter Bright:

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

The roadmap for the next three versions of Scala. Despite Scala is used much more than D, they are willing to break library code (shuffle around collections, turn mutable ones into immutable ones), and change first of all the type system, to consolidate and simplify it (beside making the compiler faster, removing bugs, introducing value types, etc):

http://scala-lang.org/news/roadmap-next

I am not a Scala expert, but those look like significant changes.

Bye,
bearophile