October 11

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

>

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

>

On Monday, 11 October 2021 at 09:21:48 UTC, FeepingCreature wrote:

>

On Monday, 11 October 2021 at 08:55:56 UTC, Imperatorn wrote:

>

In that case you would just declare x outside and do the call in the try

Thus once again demonstrating that for a language that had a major version change over it, D2 really doesn't care about immutable.

I don't know about that. But it's pretty standard for try to introduce a scope.

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.

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!)

October 11

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

>

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

>

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

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!)

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.)

October 11

On Sunday, 10 October 2021 at 16:12:31 UTC, Carl Sturtivant wrote:

>

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?

My gut instinct tells me problems would arise if try didn't introduce a scope. It's not a compile time concept like static if.

If we had a static try I would probably agree

October 11

On Monday, 11 October 2021 at 11:42:52 UTC, FeepingCreature wrote:

>

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

>

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

>

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

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!)

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.

October 11

On Monday, 11 October 2021 at 12:20:11 UTC, bauss wrote:

>

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.

No I mean:

struct Problem
{
    immutable int value;
}

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

And it errors out.

Types like these are a crapshoot in D2 even now.

October 11

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

>

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.

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;
October 11

On Monday, 11 October 2021 at 13:45:02 UTC, Paul Backus wrote:

>

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

>

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.

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.

The goal is the same as export try - avoid having to define a variable in a separate block just to handle errors.

October 11

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

>

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.

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.

>

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.

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.

October 12

On Monday, 11 October 2021 at 16:23:30 UTC, Paul Backus wrote:

>

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

>

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.

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.

Right, hence export try.

>

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.

Right, sorry. I've been meaning to add a feature for that: frgl().handle(Exception ex: return false;), but it isn't in yet.

Next ›   Last »
1 2