• Radu (1/1) Apr 16 2018 A blocker for more advanced 'betterC' usage.
• jmh530 (2/3) Apr 16 2018 https://issues.dlang.org/show_bug.cgi?id=18493
• Mike Parker (2/5) Apr 16 2018 Noted!
• Mike Franklin (10/13) Apr 16 2018 From what I can gather this appears to be caused by a
• Nicholas Wilson (10/24) Apr 16 2018 It should be a no-op under betterC because betterC implies
• Mike Franklin (5/12) Apr 16 2018 I believe `scope(exit)` is fine because it is basically
• Radu (19/33) Apr 16 2018 This is very odd, as the following compiles:
• Mike Franklin (6/24) Apr 17 2018 Yeah! I think that is also a bug. So (at least right now in my
• Radu (6/33) Apr 17 2018 Making it work without `scope(failure)` in -betterC mode should
• Mike Franklin (17/40) Apr 17 2018 Nope, that's not a bug. The reason the try-catch is only

Radu <void null.pt> writes:

A blocker for more advanced 'betterC' usage.

jmh530 <john.michael.hall gmail.com> writes:

On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
 A blocker for more advanced 'betterC' usage.

https://issues.dlang.org/show_bug.cgi?id=18493

Mike Parker <aldacron gmail.com> writes:

On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote:
 On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
 A blocker for more advanced 'betterC' usage.

 https://issues.dlang.org/show_bug.cgi?id=18493

Noted!

Mike Franklin <slavo5150 yahoo.com> writes:

On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote:
 On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
 A blocker for more advanced 'betterC' usage.

 https://issues.dlang.org/show_bug.cgi?id=18493

 From what I can gather this appears to be caused by a 
`scope(failure)` statement 
(https://dlang.org/spec/statement.html#scope-guard-statement) 
being added to the Postblit body (a.k.a. __fieldPostblit 
internally in the compiler).  I'm assuming `scope(failure)` is 
just syntactic sugar for a try-catch.

I don't know how Walter wants to handle such a situation in 
-betterC.  If I knew, I might be able to fix this bug.

Mike

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

On Tuesday, 17 April 2018 at 00:08:07 UTC, Mike Franklin wrote:
 On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote:
 On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
 A blocker for more advanced 'betterC' usage.

 https://issues.dlang.org/show_bug.cgi?id=18493

 From what I can gather this appears to be caused by a 
 `scope(failure)` statement 
 (https://dlang.org/spec/statement.html#scope-guard-statement) 
 being added to the Postblit body (a.k.a. __fieldPostblit 
 internally in the compiler).  I'm assuming `scope(failure)` is 
 just syntactic sugar for a try-catch.

 I don't know how Walter wants to handle such a situation in 
 -betterC.  If I knew, I might be able to fix this bug.

 Mike

It should be a no-op under betterC because betterC implies 
nothrow.
It is odd though since

void foo (){}
extern(C) void main()
{
     scope(exit) foo();
}

compiles and runs with -betterC

Mike Franklin <slavo5150 yahoo.com> writes:

On Tuesday, 17 April 2018 at 00:27:07 UTC, Nicholas Wilson wrote:

 It is odd though since

 void foo (){}
 extern(C) void main()
 {
     scope(exit) foo();
 }

 compiles and runs with -betterC

I believe `scope(exit)` is fine because it is basically 
try-finally, but `scope(failure)` won't work because it is 
try-catch.

Mike

Radu <void null.pt> writes:

On Tuesday, 17 April 2018 at 00:08:07 UTC, Mike Franklin wrote:
 On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote:
 On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote:
 A blocker for more advanced 'betterC' usage.

 https://issues.dlang.org/show_bug.cgi?id=18493

 From what I can gather this appears to be caused by a 
 `scope(failure)` statement 
 (https://dlang.org/spec/statement.html#scope-guard-statement) 
 being added to the Postblit body (a.k.a. __fieldPostblit 
 internally in the compiler).  I'm assuming `scope(failure)` is 
 just syntactic sugar for a try-catch.

 I don't know how Walter wants to handle such a situation in 
 -betterC.  If I knew, I might be able to fix this bug.

 Mike

This is very odd, as the following compiles:
---
struct S
{
     this(this)
     {
     }

     ~this()
     {
     }
}

struct C
{
     S s1;
}
---

If the scope failure would cause this then I assume it would not 
work at all in any case.

Mike Franklin <slavo5150 yahoo.com> writes:

On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:

 This is very odd, as the following compiles:
 ---
 struct S
 {
     this(this)
     {
     }

     ~this()
     {
     }
 }

 struct C
 {
     S s1;
 }
 ---

 If the scope failure would cause this then I assume it would 
 not work at all in any case.

Yeah! I think that is also a bug.  So (at least right now in my 
investigation) I think we first need to fix it so that it emits 
the error even with a single statement, and then fix it so it no 
longer generates the `scope(failure)` in -betterC.

Mike

Radu <void null.pt> writes:

On Tuesday, 17 April 2018 at 12:13:06 UTC, Mike Franklin wrote:
 On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:

 This is very odd, as the following compiles:
 ---
 struct S
 {
     this(this)
     {
     }

     ~this()
     {
     }
 }

 struct C
 {
     S s1;
 }
 ---

 If the scope failure would cause this then I assume it would 
 not work at all in any case.

 Yeah! I think that is also a bug.  So (at least right now in my 
 investigation) I think we first need to fix it so that it emits 
 the error even with a single statement, and then fix it so it 
 no longer generates the `scope(failure)` in -betterC.

 Mike

Making it work without `scope(failure)` in -betterC mode should 
be the goal of the fix, as the simple case (just one member) 
doesn't generate any `scope(failure)`, at least the AST ouput 
(https://run.dlang.io/is/l5CicG) doesn't contain it.

Thanks for looking into it!

Mike Franklin <slavo5150 yahoo.com> writes:

On Tuesday, 17 April 2018 at 12:13:06 UTC, Mike Franklin wrote:
 On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:

 This is very odd, as the following compiles:
 ---
 struct S
 {
     this(this)
     {
     }

     ~this()
     {
     }
 }

 struct C
 {
     S s1;
 }
 ---

 If the scope failure would cause this then I assume it would 
 not work at all in any case.

 Yeah! I think that is also a bug.

Nope, that's not a bug.  The reason the try-catch is only 
generated with two or more fields is to ensure that if an 
exception is thrown while blitting `s2`, `s1`'s destructor will 
still be called.

I'm not sure what the proper fix is yet.  The compiler could 
require you to attribute `this(this)` with `nothrow` in order to 
promise the compiler that it won't throw.  Then the compiler 
would know that it wouldn't need to add the try-catch around the 
postblit because there's no way for it to throw.  That would also 
ensure consistent behavior when compiling the same code with or 
without -betterC.

However, since throwing is off-limits entirely for -betterC, it 
doesn't make much sense to generate try-catch statements, only to 
have the compiler emit an error about it.

Maybe I should implement both. I need to sleep on it.

Mike