Value Type Exceptions

Sep 19

Richard (Rikki) Andrew Cattermole

Sep 22

IchorDev

Sep 22

Richard (Rikki) Andrew Cattermole

Sep 25

IchorDev

Sep 25

Richard (Rikki) Andrew Cattermole

September 19

Value Type Exceptions

Posted by Richard (Rikki) Andrew Cattermole

Permalink

Richard (Rikki) Andrew Cattermole

Permalink

Many people around these parts have read my proposal from August 2022 for value type exceptions.

Now is the time, to put them here officially.

In response to the original proposal, is the origin of my interest on sumtypes, matching, member-of-operator. All of these things come together to form this proposal. They are effectively designed together, requirements filter between each to give a clean design that will give a good user experience for when laziness or costs are a concern.

Latest: https://gist.github.com/rikkimax/883dddc4a61134d4c17cb18727287d92

Current: https://gist.github.com/rikkimax/883dddc4a61134d4c17cb18727287d92/f8fa440535ac4ec089efe940e8daddeb658556dc

It has applied Walter's carry flag idea from DConf 2024, to elide the tag value of the tagged union. Allowing for an even cheaper throw.

So what is included?

Default for functions remains to be throwing a Exception, specifying the empty set is equivalent to nothrow.
The introduction of the throw set @throw(...).
The throw set may include structs, member-of-operator and classes that inherit from Throwable.
A catch-all that is represented by sumtypes } catch(sumtype varName) {
When using a struct, support an optional low-cost backtrack method by only using compiler information.
Structs support copy constructor and destructor, see my sumtype proposal on how the variable layout works.
Did I mention the throw set is inferred? Sadly it cannot shrink down to the empty set due to virtual functions/function pointers, but we could change that with an edition if it's desirable to do so.

int toCall() @throw(:FailedToDecodeUTF) {
    throw :FailedToDecodeUTF;
}

int caller() /* @throw() */ {
    int result;

    try {
        result = toCall();
    } catch(:FailedToDecodeUTF) {
        result = 0xDEADBEEF;
    }

    return result;
}

int toCall() @throw(:FailedToDecodeUTF) { throw :FailedToDecodeUTF; } int caller() /* @throw() */ { int result; try { result = toCall(); } catch(:FailedToDecodeUTF) { result = 0xDEADBEEF; } return result; }

On 22/09/2024 10:25 PM, IchorDev wrote: > On Thursday, 19 September 2024 at 18:31:02 UTC, Richard (Rikki) Andrew Cattermole wrote: >> - Did I mention the throw set is inferred? Sadly it cannot shrink down to the empty set due to virtual functions/function pointers, but we could change that with an edition if it's desirable to do so. >> >> ```d >> int toCall() @throw(:FailedToDecodeUTF) { >> throw :FailedToDecodeUTF; >> } >> >> int caller() /* @throw() */ { >> int result; >> >> try { >> result = toCall(); >> } catch(:FailedToDecodeUTF) { >> result = 0xDEADBEEF; >> } >> >> return result; >> } >> ``` > > But if `caller` is manually marked nothrow then it wouldn’t be a compiler error anymore just because you didn’t catch `Exception`? ``nothrow`` is equivalent to the empty set ``@throw()``, so in the example it is ``nothrow``. So I'm not sure what you are asking? > Also, could you elaborate on what `:FailedToDecodeUTF` is in this situation? Like, what exactly is it a member of? The sumtype that represents the exceptions, specifically a tag that has no payload. See my sumtype proposal, this would use that under the hood.

On Sunday, 22 September 2024 at 15:37:04 UTC, Richard (Rikki) Andrew Cattermole wrote:

On 22/09/2024 10:25 PM, IchorDev wrote:

But if caller is manually marked nothrow then it wouldn’t be a compiler error anymore just because you didn’t catch Exception?

nothrow is equivalent to the empty set @throw(), so in the example it is nothrow.

So I'm not sure what you are asking?

In other words, when calling a throwing function, if you catch everything in the throw set then can your function be marked nothrow? Right now, you have to catch Exception to mark your function nothrow, even if you catch every exception type that function can throw individually.

> >

Also, could you elaborate on what :FailedToDecodeUTF is in this situation? Like, what exactly is it a member of?

The sumtype that represents the exceptions, specifically a tag that has no payload.

See my sumtype proposal, this would use that under the hood.

Yes but what would the sum type declaration look like, for instance? What is typeof(:FailedToDecodeUTF)? The sum type DIP mentions something about being able to expand a sum type's constraint set; but I didn’t see any examples of it, and this would surely be a place where that constraint set expansion is utilised, no?

On 26/09/2024 9:36 AM, IchorDev wrote: > On Sunday, 22 September 2024 at 15:37:04 UTC, Richard (Rikki) Andrew Cattermole wrote: >> On 22/09/2024 10:25 PM, IchorDev wrote: >>> But if `caller` is manually marked nothrow then it wouldn’t be a compiler error anymore just because you didn’t catch `Exception`? >> >> ``nothrow`` is equivalent to the empty set ``@throw()``, so in the example it is ``nothrow``. >> >> So I'm not sure what you are asking? > > In other words, when calling a throwing function, if you catch everything in the throw set then can your function be marked nothrow? Right now, you have to catch `Exception` to mark your function `nothrow`, even if you catch every exception type that function can throw individually. Yes. ``nothrow`` becomes ``@throw()``. It is 1:1, just different syntax. >>> Also, could you elaborate on what `:FailedToDecodeUTF` is in this situation? Like, what exactly is it a member of? >> >> The sumtype that represents the exceptions, specifically a tag that has no payload. >> >> See my sumtype proposal, this would use that under the hood. > > Yes but what would the sum type declaration look like, for instance? What is `typeof(:FailedToDecodeUTF)`? The sum type DIP mentions something about being able to expand a sum type's constraint set; but I didn’t see any examples of it, and this would surely be a place where that constraint set expansion is utilised, no? ``typeof(:FailedToDecodeUTF)`` is defined by the member-of-operator proposal. That is how you get access to the type, it has no declaration associated with it. We have an example of this in the language already ``alias noreturn = typeof(*null);``. Note: an alias is not a type declaration, a typedef is one however. As for expansion, I'm going to need more to go on, I haven't used the word "expan*" in any of them.

Forums