digitalmars.dip.ideas - Value Type Exceptions
- Richard (Rikki) Andrew Cattermole (46/46) Sep 19 Many people around these parts have read my proposal from August
- IchorDev (6/24) Sep 22 But if `caller` is manually marked nothrow then it wouldn’t be a
- Richard (Rikki) Andrew Cattermole (7/35) Sep 22 ``nothrow`` is equivalent to the empty set ``@throw()``, so in the
- IchorDev (13/26) Sep 25 In other words, when calling a throwing function, if you catch
- Richard (Rikki) Andrew Cattermole (13/42) Sep 25 Yes.
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. ```d int toCall() throw(:FailedToDecodeUTF) { throw :FailedToDecodeUTF; } int caller() /* throw() */ { int result; try { result = toCall(); } catch(:FailedToDecodeUTF) { result = 0xDEADBEEF; } return result; } ```
Sep 19
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`?
Also, could you elaborate on what `:FailedToDecodeUTF` is in this
situation? Like, what exactly is it a member of?
Sep 22
On 22/09/2024 10:25 PM, IchorDev wrote:On Thursday, 19 September 2024 at 18:31:02 UTC, Richard (Rikki) Andrew Cattermole wrote:``nothrow`` is equivalent to the empty set `` throw()``, so in the example it is ``nothrow``. So I'm not sure what you are asking?- 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`?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.
Sep 22
On Sunday, 22 September 2024 at 15:37:04 UTC, Richard (Rikki) Andrew Cattermole wrote:On 22/09/2024 10:25 PM, IchorDev wrote: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.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?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?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.
Sep 25
"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> On 26/09/2024 9:36 AM, IchorDev wrote:On Sunday, 22 September 2024 at 15:37:04 UTC, Richard (Rikki) Andrew Cattermole wrote:Yes. ``nothrow`` becomes `` throw()``. It is 1:1, just different syntax.On 22/09/2024 10:25 PM, IchorDev wrote: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.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?``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.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?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.
Sep 25