Why does this code

import std.stdio,std.typecons;

struct EC {
   Exception [] ex;
   auto opAssign (X: void) (lazy X f)
   {
      writeln (__PRETTY_FUNCTION__);
      try return f (); catch (Exception e) ex ~= e;
   }
}

class E : Exception { this (string s) { super (s); } }
void bar (int i) { if (i == 1) throw new E ("E"); }

void main ()
{
   EC ec;

   ec.opAssign (bar (1)); // okay
//   ec = bar (1); // Error: expression bar(1) is void and has no value

   ec.writeln;
}

compile with the abovementioned error?

On Saturday, 3 April 2021 at 13:46:17 UTC, kdevel wrote:

You cannot assign void returned from bar() as parameter to opAssign(). The lazy keyword creates some internal delegate, thus opAssign() works instead. I'm afraid lazy storage class only works with arguments, not rvalues.

On Sunday, 4 April 2021 at 16:38:10 UTC, frame wrote:

Thus, the solution is to use an explicit delegate instead of lazy:

import std.stdio,std.typecons;

struct EC {
   Exception [] ex;
   auto opAssign (X: void delegate()) (scope X f)
   {
      writeln (__PRETTY_FUNCTION__);
      try return f (); catch (Exception e) ex ~= e;
   }
}

class E : Exception { this (string s) { super (s); } }
auto bar (int i) {
    return () {
    	if (i == 1)
            throw new E ("E");
    };
}

void main ()
{
   EC ec;

   ec = bar (1); // okay

   ec.writeln;
}

On Sunday, 4 April 2021 at 18:05:04 UTC, tsbockman wrote:

Yes, I forgot to mention that.
Could you please explain why you set 'scope' here? Isn't it wanted to keep references here?

On Sunday, 4 April 2021 at 18:05:04 UTC, tsbockman wrote:

[...]
>> You cannot assign void returned from bar() as parameter to opAssign(). The lazy keyword creates some internal delegate, thus opAssign() works instead.
[...]
> auto bar (int i) {
>     return () {
>     	if (i == 1)
>             throw new E ("E");
>     };
> }

You changed the definition of bar while the exception collector (EC) is meant to catch and collect an exception thrown from the unmodified function. It seems that the operator += or ~= may be better suited to express that intent. Rewriting this in terms of opOpAssign works as expected:

import std.stdio;

struct EC {
   Exception [] ex;
   auto opOpAssign (string op: "+", X: void) (lazy X f)
   {
      writeln (__PRETTY_FUNCTION__);
      try return f (); catch (Exception e) ex ~= e;
   }
   auto opOpAssign (string op: "~", X: void) (lazy X f)
   {
      writeln (__PRETTY_FUNCTION__);
      try return f (); catch (Exception e) ex ~= e;
   }
}

class E : Exception { this (string s) { super (s); } }
void bar (int i) { if (i == 1) throw new E ("E"); }

void main ()
{
   EC ec;

   ec.opOpAssign!"+" (bar (1)); // okay
   ec += bar (1); // okay
   ec ~= bar (1); // okay

   ec.writeln;
}

On Monday, 5 April 2021 at 15:05:24 UTC, kdevel wrote:

[...]
>> [...]
[...]
> [...]

Nice, is this documented somewhere? 🤔
Maybe we could add a better error message or smth.

On Monday, 5 April 2021 at 15:05:24 UTC, kdevel wrote:

My point was that the code will work if you do explicitly what lazy does implicitly. If you don't want to modify bar, then it looks like this:

import std.stdio,std.typecons;

struct EC {
    Exception [] ex;
    auto opAssign (X) (scope X f)
        if(is(X : void delegate()) || is(X : void function()))
    {
        writeln (__PRETTY_FUNCTION__);
        try return f (); catch (Exception e) ex ~= e;
    }
}

class E : Exception { this (string s) { super (s); } }
void bar (int i) { if (i == 1) throw new E ("E"); }

void main ()
{
    EC ec;

    ec = () { bar (1); }; // okay

    ec.writeln;
}

Given that you define the operation to append ~ to ex rather than overwriting it, ~= is the best fit, I think.

However, = and ~= should not treat lazy void parameters differently. They should either both work, or neither. I checked and this is actually a very old regression; both worked way back in DMD 2.061. So, I've filed a front-end bug report:
https://issues.dlang.org/show_bug.cgi?id=21802

On Monday, 5 April 2021 at 05:22:22 UTC, frame wrote:

scope here indicates that no references to the f delegate itself will be escaped from opAssign, giving the caller the option of allocating the closure on the stack.

opAssign may retain a reference to an Exception thrown by the delegate, but that's OK because the Exception is not part of the f delegate data structure, not even indirectly or transitively. (I can explain/justify this in more detail if that still doesn't make sense.)

On Monday, 5 April 2021 at 20:59:34 UTC, tsbockman wrote:

Thanks!

On Saturday, 3 April 2021 at 13:46:17 UTC, kdevel wrote:

   ec.opAssign (bar (1)); // okay
//   ec = bar (1); // Error: expression bar(1) is void and has no value

This is a compiler bug. You're not allowed to have a void expression on the right-hand side of an assignment, but you are allowed to pass a void expression to a function that takes a lazy parameter. Currently, the compiler checks for errors before rewriting the assignment to an opAssign call, which means that it will issue an error even in cases where the rewrite would have worked. What it should do instead is rewrite the assignment first, and then check for errors.