Value Type Exceptions

[Richard (Rikki) Andrew Cattermole]

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.