On Monday, 11 October 2021 at 09:23:27 UTC, Imperatorn wrote:

The problem is if you want to use immutable types at all, this forces you to either use awkward nested function idioms with tuple returns for more than one variable, put the entire remaining function body in the try block. It makes it impossible to keep try small.

One possible solution would be a way to try/catch as an expression:

auto x = frgl().tryCatch(Exception exc: return exc;);

But D has no precedent for statements embedded in expressions like this, so it'd be a major language shift.

export try is the only feasible approach I can see offhand.

On Monday, 11 October 2021 at 09:27:30 UTC, FeepingCreature

Using alias this, opAssign and a boolean value you can actually do something like this:

public struct BindOnce(T)
{
    private bool _isSet;
    private T _value;

    alias _value this;

    void opAssign(T rhs)
    {
        if (_isSet)
        {
            throw new Error("The value has already been set.");
        }

        _isSet = true;
        _value = rhs;
    }

    string toString() { return to!string(_value); } // Required for writeln
}

Example Usage:

int getNumber(int input)
{
    if (input == 0) throw new Exception("This function doesn't allow multiplications of zero.");
    return input * 2;
}

void main()
{
    BindOnce!int n;
    try
    {
        n = getNumber(20);
        //n = getNumber(40); // Uncommenting this line will throw the error "The value has already been set."

        writeln(n);
    }
    catch (Exception e)
    {
        writeln(e);
        writeln(n);
    }
}

Of course this assumes you're able to allow runtime errors and that you don't blindly catches them and ignores them either (which you shouldn't as Error shouldn't be recoverable!)

Why is it that a try block is defined to establish a scope?

    try {
        auto x = frgl();
    }
    // ...
    // x undefined here

What is the benefit of this? If try (like static if/foreach) did NOT establish a scope, then this annoyance would go away. And if a scope was desired for some reason, then an extra pair of braces could be written within.

Right now rewriting the above requires getting the return type of frgl and declaring x to be of that type before the try block.

Design error?

On Monday, 11 October 2021 at 11:05:47 UTC, bauss wrote:

public struct BindOnce(T)
{
    private bool _isSet;
    private T _value;

    alias _value this;

    void opAssign(T rhs)
    {
        if (_isSet)
        {
            throw new Error("The value has already been set.");
        }

        _isSet = true;
        _value = rhs;
    }

    string toString() { return to!string(_value); } // Required for writeln
}

int getNumber(int input)
{
    if (input == 0) throw new Exception("This function doesn't allow multiplications of zero.");
    return input * 2;
}

void main()
{
    BindOnce!int n;
    try
    {
        n = getNumber(20);
        //n = getNumber(40); // Uncommenting this line will throw the error "The value has already been set."

        writeln(n);
    }
    catch (Exception e)
    {
        writeln(e);
        writeln(n);
    }
}

I almost don't want to say it.

Cough immutable cough...

That's why this really needs language support.

(Also I'd just use Nullable or Rebindable irl.)

Yeah, I'm aware it's not necessarily "immutable" in the standard sense, but it is in the technical sense.

Of course the export try would be much better but this is a somewhat viable solution until, as you can easily replace it with immutable once/if ever supported.

One possible solution would be a way to try/catch as an expression:

auto x = frgl().tryCatch(Exception exc: return exc;);

But D has no precedent for statements embedded in expressions like this, so it'd be a major language shift.

On Monday, 11 October 2021 at 09:27:30 UTC, FeepingCreature wrote:

auto x = frgl().tryCatch(Exception exc: return exc;);

import std.sumtype;

SumType!(V, E) tryCatch(E, V)(lazy V expr)
{
    try return typeof(return)(expr);
    catch (E e) return typeof(return)(e);
}

auto x = frgl().tryCatch!Exception;

Sure, but then you can't get at the V without - going into a subscope again. :) Though I guess it wouldn't be covered by a try.

Neat (my lang) doesn't have exceptions, but it does have built-in sumtypes with error marking, so you can have

(V | fail Exception) frgl() { ... }

auto x <- frgl();

And it will "pick" the non-fail V and, in the case of Exception, just propagate (return) it.

On Monday, 11 October 2021 at 16:04:00 UTC, FeepingCreature wrote:

At some point, you need to have separate code paths for the error case and the success case, yes. I know of no language construct in D that allows you to create separate code paths without introducing a scope somewhere. The best you can do is move the scopes around.

In D, you can also write auto x = frgl();, and it will propagate the exception automatically. :)

This is not a replacement for try blocks, because the reason you use a try block is to handle an exception locally; in other words, to avoid propagating it.