Hi,

I noticed, that I cannot throw from the lambda expression:
  Error: expression expected, not throw
but have to use the longer syntax () {throw new Exception();}

---
void foo(void function() e){}

void main()
{
    foo(
        () => throw new Exception()
    );
}
---

The shorter lambda syntax would be more readable in my case.
Is there a reason why it isn't allowed or should I create an
enhancement request?

Kind regards
André

On Monday, 9 September 2019 at 09:14:08 UTC, Andre Pany wrote:
> Hi,
>
> I noticed, that I cannot throw from the lambda expression:
>   Error: expression expected, not throw
> but have to use the longer syntax () {throw new Exception();}
>
> ---
> void foo(void function() e){}
>
> void main()
> {
>     foo(
>         () => throw new Exception()
>     );
> }
> ---
>
> The shorter lambda syntax would be more readable in my case.
> Is there a reason why it isn't allowed or should I create an
> enhancement request?
>
> Kind regards
> André

Well, the shorthand syntax "=>" implies a return, but you can only return an expression and throw is a statement.

https://dlang.org/spec/expression.html#lambdas

On Monday, 9 September 2019 at 09:14:08 UTC, Andre Pany wrote:
> I noticed, that I cannot throw from the lambda expression:
>   Error: expression expected, not throw
> but have to use the longer syntax () {throw new Exception();}
>
> ---
> void foo(void function() e){}
>
> void main()
> {
>     foo(
>         () => throw new Exception()
>     );
> }
> ---
>
> The shorter lambda syntax would be more readable in my case.
> Is there a reason why it isn't allowed or should I create an
> enhancement request?
>

and next code too. C# code good is it
int func( bool ok ) {
    return ok ? 123 : throw new Exception( "oops 123");
}

cuz throwing exception ever is not compatible with any return type so I dont see reasons do not allow such expressions

On Monday, 9 September 2019 at 09:37:25 UTC, a11e99z wrote:
> On Monday, 9 September 2019 at 09:14:08 UTC, Andre Pany wrote:
>> I noticed, that I cannot throw from the lambda expression:
>>   Error: expression expected, not throw
>> but have to use the longer syntax () {throw new Exception();}
>>
>> ---
>> void foo(void function() e){}
>>
>> void main()
>> {
>>     foo(
>>         () => throw new Exception()
>>     );
>> }
>> ---
>>
>> The shorter lambda syntax would be more readable in my case.
>> Is there a reason why it isn't allowed or should I create an
>> enhancement request?
>>
>
> and next code too. C# code good is it
> int func( bool ok ) {
>     return ok ? 123 : throw new Exception( "oops 123");
> }
>
> cuz throwing exception ever is not compatible with any return type so I dont see reasons do not allow such expressions

Thanks for the answers.
I will create an enhancement requests and add the C# example.

Kind regards
André

On Monday, 9 September 2019 at 09:37:25 UTC, a11e99z wrote:
> cuz throwing exception ever is not compatible with any return type so I dont see reasons do not allow such expressions

A throw statement can actually be seen as an expression returning a 'never' / 'bottom' type which is implicitly convertible to any return type. This is actually a really good example for the value of a bottom type as suggested in DIP1017:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1017.md

Such a shame it got rejected in favor of ugly 'no return' annotations, if only the DIP pointed out other use cases. Looking at the Formal Assessment section:
"He (Walter Bright) still thinks there is value in adding a bottom type to the language, but has decided to revisit the issue at a later date."

I hope a bottom type resolves this issue with throw statements in lambdas instead of another hack such as 'no return'.

On Monday, 9 September 2019 at 10:46:10 UTC, Dennis wrote:
> Such a shame it got rejected in favor of ugly 'no return' annotations [...]

This is incorrect. It was rejected because the proposal was not solid enough. While it is true that a lot of people seemed to prefer an annotation based solution during the discussion, no such solution has been accepted into the language yet (at least as far as I know). Personally, I favor the bottom type solution and the problems described in this thread could be part of a good rationale for a new DIP proposing a bottom type. It just needs somebody to come up with a solid proposal.

On Monday, 9 September 2019 at 13:22:22 UTC, Johannes Loher wrote:
> This is incorrect. It was rejected because the proposal was not solid enough.

I put that a bit bluntly, but as far as I see it, the DIP focused too much on only adding a way to mark functions as 'no return' that people were like "if all you want to do is tell the compiler a function does not return, an attribute is sufficient. A new type is overkill.".
Add some discussion about the name TBottom and the fact that community feedback wasn't addressed and the DIP was deemed dead on arrival as Walter put it.

> It just needs somebody to come up with a solid proposal.

I might give it a try actually.