www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Discussion Thread: DIP 1029--Add throw as Function Attribute--Final

reply Mike Parker <aldacron gmail.com> writes:
This is the discussion thread for the Final Review of DIP 1029, 
"Add throw as Function Attribute":

https://github.com/dlang/DIPs/blob/9db80ddadcf5a220958ddcfec14b9c71cdb43d1c/DIPs/DIP1029.md

The review period will end at 11:59 PM ET on May 1, or when I 
make a post declaring it complete. Discussion in this thread may 
continue beyond that point.

Here in the discussion thread, you are free to discuss anything 
and everything related to the DIP. Express your support or 
opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the 
proposal itself, then please post it in the feedback thread. The 
feedback thread will be the source for the review summary I write 
at the end of this review round. I will post a link to that 
thread immediately following this post. Just be sure to read and 
understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and 
Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are 
completely off-topic.
Apr 17 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 17 April 2020 at 11:28:05 UTC, Mike Parker wrote:


 However, if you have any specific feedback on how to improve 
 the proposal itself, then please post it in the feedback 
 thread. The feedback thread will be the source for the review 
 summary I write at the end of this review round. I will post a 
 link to that thread immediately following this post.


The feedback thread is here:

https://forum.dlang.org/post/qhtqeavhyzjfamhgcjjl forum.dlang.org
Apr 17 2020
parent reply James Lu <jamtlu gmail.com> writes:
On Friday, 17 April 2020 at 11:31:21 UTC, Mike Parker wrote:

 On Friday, 17 April 2020 at 11:28:05 UTC, Mike Parker wrote:


 However, if you have any specific feedback on how to improve 
 the proposal itself, then please post it in the feedback 
 thread. The feedback thread will be the source for the review 
 summary I write at the end of this review round. I will post a 
 link to that thread immediately following this post.


 The feedback thread is here:

 https://forum.dlang.org/post/qhtqeavhyzjfamhgcjjl forum.dlang.org


If I understand correctly, nothrow functions may throw Errors, 
but throw functions may throw Errors and Exceptions?
If a nothrow function throws an Error, may the outer function 
catch it in a well-defined manner?
Apr 17 2020
parent FeepingCreature <feepingcreature gmail.com> writes:
On Friday, 17 April 2020 at 12:58:56 UTC, James Lu wrote:

 On Friday, 17 April 2020 at 11:31:21 UTC, Mike Parker wrote:

 On Friday, 17 April 2020 at 11:28:05 UTC, Mike Parker wrote:


 However, if you have any specific feedback on how to improve 
 the proposal itself, then please post it in the feedback 
 thread. The feedback thread will be the source for the review 
 summary I write at the end of this review round. I will post 
 a link to that thread immediately following this post.


 The feedback thread is here:

 https://forum.dlang.org/post/qhtqeavhyzjfamhgcjjl forum.dlang.org


 If a nothrow function throws an Error, may the outer function 
 catch it in a well-defined manner?


Catching `Error` is always undefined. That's why nothrow may 
throw them in the first place.
Apr 17 2020
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
No objection to it as written, but there have been zero changes 
to the text between this review and the last, except adding the 
summary of the (apparently ignored by the author) previous round.

What's the point of going over an identical document again?
Apr 17 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/17/20 8:52 AM, Adam D. Ruppe wrote:

 No objection to it as written, but there have been zero changes to the 
 text between this review and the last, except adding the summary of the 
 (apparently ignored by the author) previous round.


There is a difference between ignored and advice considered and not taken.

Though I think in at least one case (I posted on the review thread) 
something important was missed.

-Steve
Apr 17 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 17 April 2020 at 14:39:26 UTC, Steven Schveighoffer 
wrote:

 There is a difference between ignored and advice considered and 
 not taken.


But even if it was all simply not taken, I'm OK with a response 
"I don't care, take it or leave it" (though two of the bullets 
don't even have that, just nothing)... but why are we wasting our 
time doing a discussion thread to review the same document again?

Again, the text is *identical* to the last review, so what does 
the DIP manager expect from us this time that would be any 
different than last time?

We complain that newsgroup discussions go in circles. Well, this 
is literally called a "round" lol, but it just seems ridiculous.
Apr 17 2020
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/17/20 1:01 PM, Adam D. Ruppe wrote:

 On Friday, 17 April 2020 at 14:39:26 UTC, Steven Schveighoffer wrote:

 There is a difference between ignored and advice considered and not 
 taken.


 
 But even if it was all simply not taken, I'm OK with a response "I don't 
 care, take it or leave it" (though two of the bullets don't even have 
 that, just nothing)... but why are we wasting our time doing a 
 discussion thread to review the same document again?


I think it's just part of the red tape we created for ourselves!

But it also gives the chance to reiterate the importance of advice not 
taken, or rephrase the argument in a way that is more convincing.


 Again, the text is *identical* to the last review, so what does the DIP 
 manager expect from us this time that would be any different than last 
 time?


This is how things like this work. There are responses to the points 
made, and Walter didn't make any changes based on that.

It would also be possible to amend the DIP process such that if no 
changes are made before final review, it goes straight to formal 
assessment. Might not be a bad idea. It would save time too.

The document is here: 
https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md#final-review

It says:


 The purpose of the Final Review is to provide one final opportunity to examine
the revisions made in response to the Community Review rounds and further
refine the DIP as necessary.


So, just amend that to say "If no revisions were made in response to the 
Community reviews, the DIP manager may forego the Final Review stage".

-Steve
Apr 17 2020
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 17 April 2020 at 17:01:31 UTC, Adam D. Ruppe wrote:

 On Friday, 17 April 2020 at 14:39:26 UTC, Steven Schveighoffer 
 wrote:

 There is a difference between ignored and advice considered 
 and not taken.


 But even if it was all simply not taken, I'm OK with a response 
 "I don't care, take it or leave it" (though two of the bullets 
 don't even have that, just nothing)... but why are we wasting 
 our time doing a discussion thread to review the same document 
 again?

 Again, the text is *identical* to the last review, so what does 
 the DIP manager expect from us this time that would be any 
 different than last time?

 We complain that newsgroup discussions go in circles. Well, 
 this is literally called a "round" lol, but it just seems 
 ridiculous.


Please start a new thread if you want to discuss the DIP process 
and let's keep this one focused on the DIP. Thanks!
Apr 17 2020
prev sibling next sibling parent James Lu <jamtlu gmail.com> writes:
On Friday, 17 April 2020 at 11:28:05 UTC, Mike Parker wrote:

 This is the discussion thread for the Final Review of DIP 1029, 
 "Add throw as Function Attribute":

 [...]


Have the ideas below been discussed?

- an attribute "exception_aware": does the function body use 
catch or throw?
- using "!!" to designate attribute remove: !!pure, !!nothrow. It 
is visible, it is explicit.
Apr 17 2020
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-04-17 13:28, Mike Parker wrote:

 This is the discussion thread for the Final Review of DIP 1029, "Add 
 throw as Function Attribute":
 
 https://github.com/dlang/DIPs/blob/9db80ddadcf5a220958ddcfec14b9c71cdb4
d1c/DIPs/DIP1029.md 


I would like to see the "throw" keyword being used as an attribute to 
implement something like "Zero-overhead deterministic exceptions: 
Throwing values" [1].

I imagine it looking something like this:

enum CopyError
{
     permissionDenied
}

void copy(string src, string dest) throw(CopyError)
{
     throw CopyError.permissionDenied;
}

void main()
{
     try
         copy("foo", "bar");
     catch (CopyError e)
         writeln(e);
}

Which would be lowered to something like the equivalent of the following 
code:

struct Result(Value, Error)
{
     bool isValue;
     union
     {
         Value value;
         Error error;
     }

     this(Value value)
     {
         this.value = value;
         isValue = true;
     }

     this(Error errro)
     {
         this.error = error;
         isValue = true;
     }
}

Result!(void, CopyError) copy(string src, string dest)
{
     return Result!(void, CopyError)(CopyError.permissionDenied);
}

void main()
{
     auto result = copy("foo", "bar");

     if (!result.isValue)
         goto L1;
     L1:
         writeln(result.error);
}


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

-- 
/Jacob Carlborg
Apr 18 2020
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 18 April 2020 at 12:03:46 UTC, Jacob Carlborg wrote:

 Result!(void, CopyError) copy(string src, string dest)
 {
     return Result!(void, CopyError)(CopyError.permissionDenied);
 }

 void main()
 {
     auto result = copy("foo", "bar");

     if (!result.isValue)
         goto L1;
     L1:
         writeln(result.error);
 }


The big downside of this compared to exceptions is that you can 
forget to check the return value of `copy`, whereas exceptions 
cannot be ignored.


respectively to force the programmer to check the return value. 
Without something equivalent in D, using algebraic data types for 
error handling is not really a viable approach.
Apr 18 2020
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Saturday, 18 April 2020 at 14:02:46 UTC, Paul Backus wrote:

 On Saturday, 18 April 2020 at 12:03:46 UTC, Jacob Carlborg 
 wrote:

 void main()
 {
     auto result = copy("foo", "bar");

     if (!result.isValue)
         goto L1;
     L1:
         writeln(result.error);
 }


 The big downside of this compared to exceptions is that you can 
 forget to check the return value of `copy`, whereas exceptions 
 cannot be ignored.


That part was only the lowered code.
Apr 18 2020
prev sibling parent reply NaN <divide by.zero> writes:
On Saturday, 18 April 2020 at 12:03:46 UTC, Jacob Carlborg wrote:

 On 2020-04-17 13:28, Mike Parker wrote:

 This is the discussion thread for the Final Review of DIP 
 1029, "Add throw as Function Attribute":
 
 https://github.com/dlang/DIPs/blob/9db80ddadcf5a220958ddcfec14b9c71cdb43d1c/DIPs/DIP1029.md


 I would like to see the "throw" keyword being used as an 
 attribute to implement something like "Zero-overhead 
 deterministic exceptions: Throwing values" [1].

 I imagine it looking something like this:

 enum CopyError
 {
     permissionDenied
 }

 void copy(string src, string dest) throw(CopyError)
 {
     throw CopyError.permissionDenied;
 }

 void main()
 {
     try
         copy("foo", "bar");
     catch (CopyError e)
         writeln(e);
 }

 Which would be lowered to something like the equivalent of the 
 following code:


You could have the caller pass an alternate return address to the 
callee. So...

void copy(string src, string dest, void* err)
{
     if (somethingbad) { EAX = errorcode; RET (to) err; } ***
}

void main()
{
     auto result = copy("foo", "bar", &L1);

     return;

     L1: writeln("Oh noes!");
}

*** So all the callee has to do is poke the alternate return 
address into the stack and RET as normal. (On x86 at least).
Apr 18 2020
parent Panke <tobias pankrath.net> writes:
On Saturday, 18 April 2020 at 16:28:59 UTC, NaN wrote:

 You could have the caller pass an alternate return address to 
 the callee. So...

 void copy(string src, string dest, void* err)
 {
     if (somethingbad) { EAX = errorcode; RET (to) err; } ***
 }

 void main()
 {
     auto result = copy("foo", "bar", &L1);

     return;

     L1: writeln("Oh noes!");
 }

 *** So all the callee has to do is poke the alternate return 
 address into the stack and RET as normal. (On x86 at least).


A paper describing the idea.

https://dl.acm.org/doi/pdf/10.1145/1016848.1016864

I thought there was a more practical one, but only found this.
May 05 2020
prev sibling parent reply Tove <tove fransson.se> writes:
On Friday, 17 April 2020 at 11:28:05 UTC, Mike Parker wrote:

 This is the discussion thread for the Final Review of DIP 1029, 
 "Add throw as Function Attribute":


On Tuesday, 5 May 2020 at 14:39:24 UTC, Petar Kirov [ZombineDev] 
wrote:

 Otherwise, I'd say that the best solution, which I think Andrei 
 agreed with [1] is `attribute(true)` and `attribute(false)` or 
 more generally: `attribute(boolExpr)`.

 [1]: https://forum.dlang.org/post/mknspb$1dgl$1 digitalmars.com


Good digging! I agree with you and Andrei, but using template 
syntax would be an additional improvement, it's not about saving 
one char, but avoiding matching () in the common case.

attribute!true
attribute!false
attribute!(boolExpr)
May 05 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 5 May 2020 at 15:30:38 UTC, Tove wrote:

 Good digging! I agree with you and Andrei, but using template 
 syntax would be an additional improvement, it's not about 
 saving one char, but avoiding matching () in the common case.

 attribute!true
 attribute!false
 attribute!(boolExpr)


It seems more confusing to me to use template syntax for 
something that isn't a template.

We already use parentheses for stuff like `extern(C)`. Using them 
for function attributes is a natural extension of that.
May 05 2020
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 5 May 2020 at 15:55:30 UTC, Paul Backus wrote:

 On Tuesday, 5 May 2020 at 15:30:38 UTC, Tove wrote:

 Good digging! I agree with you and Andrei, but using template 
 syntax would be an additional improvement, it's not about 
 saving one char, but avoiding matching () in the common case.

 attribute!true
 attribute!false
 attribute!(boolExpr)


 It seems more confusing to me to use template syntax for 
 something that isn't a template.

 We already use parentheses for stuff like `extern(C)`. Using 
 them for function attributes is a natural extension of that.


If we turn the existing function attributes into compiler 
recognized UDAs, the template version is one char shorter:

     version (A)
     {
         struct nogc { bool enabled; }
         void foo()  (nogc(true)) { }
     }
     else version (B)
     {
         struct nogc(bool enabled) { }
         void foo()  (nogc!true) { }
     }


;)
May 05 2020
prev sibling parent Tove <tove fransson.se> writes:
On Tuesday, 5 May 2020 at 15:55:30 UTC, Paul Backus wrote:

 On Tuesday, 5 May 2020 at 15:30:38 UTC, Tove wrote:

 Good digging! I agree with you and Andrei, but using template 
 syntax would be an additional improvement, it's not about 
 saving one char, but avoiding matching () in the common case.

 attribute!true
 attribute!false
 attribute!(boolExpr)


 It seems more confusing to me to use template syntax for 
 something that isn't a template.

 We already use parentheses for stuff like `extern(C)`. Using 
 them for function attributes is a natural extension of that.


It's not a function either and extern!C would be fine with me.

IIRC `extern(C)` existed long before the single argument template 
syntax. It may appear a minor feature, but I miss it a lot when 
forced to use other languages.
May 05 2020