• Steven Schveighoffer (27/27) Nov 22 2019 I have code in my proprietary project that looks like this:
• Jacob Carlborg (4/6) Nov 22 2019 Can you run dustmite to create a reduced example?
• Steven Schveighoffer (4/11) Nov 22 2019 I can at some point. For now, I need to keep moving. Just wondering if
• Meta (5/32) Nov 22 2019 Are you passing the -dip1000 switch to the compiler? I reproduced
• Steven Schveighoffer (6/10) Nov 22 2019 I am not. But I admit that I didn't have the return attribute at first.
• Meta (27/38) Nov 24 2019 It's just your code (@safe added for good measure):
• Steven Schveighoffer (5/53) Nov 24 2019 Oh my, I swear I put something similar into run.dlang.io and it compiled...
• Steven Schveighoffer (7/12) Nov 24 2019 The key here is that SQLStatement has a string in it. In my toy test, I
• Walter Bright (3/25) Nov 22 2019 Yes it is. See the ^^^^
• Steven Schveighoffer (12/42) Nov 23 2019 Yes, where is returning ref, but the complaint is not focused on that.
• Walter Bright (2/3) Nov 23 2019 Ok, but you're going to need to find a test case that can be put on bugz...
• Steven Schveighoffer (3/8) Nov 24 2019 https://issues.dlang.org/show_bug.cgi?id=20416
• Walter Bright (2/3) Nov 24 2019 Thank you.

Steven Schveighoffer <schveiguy gmail.com> writes:

I have code in my proprietary project that looks like this:

struct X
{
    ...
    SQLStatement foo()
    {
       auto stmt = SQLStatement("`foo`"); // table
       return stmt.where("`id` = ?", id);
    }
}

where is a function that adds a where clause with a given value to the 
SQL statement. It takes an SQLStatement by ref, and returns that 
statement by ref.

Signature looks like this:

ref SQLStatement where(T)(return ref SQLStatement stmt, string clause, T 
val)

In this case, I'm using the convenience of returning the statement to 
return that from the function.

However, the compiler is complaining:

  Error: returning where(stmt, "`id` = ?", id) escapes a reference to 
local variable stmt

But... it's not returning a ref. So why the complaint?

I have to separate into 2 lines.

I tried to make a simple example to show the problem, but looks like it 
doesn't fail in that case.

Any ideas?

-Steve

Jacob Carlborg <doob me.com> writes:

On 2019-11-22 19:54, Steven Schveighoffer wrote:

 I tried to make a simple example to show the problem, but looks like it 
 doesn't fail in that case.

Can you run dustmite to create a reduced example?

-- 
/Jacob Carlborg

Steven Schveighoffer <schveiguy gmail.com> writes:

On 11/22/19 2:40 PM, Jacob Carlborg wrote:
 On 2019-11-22 19:54, Steven Schveighoffer wrote:
 
 I tried to make a simple example to show the problem, but looks like 
 it doesn't fail in that case.

 
 Can you run dustmite to create a reduced example?
 

I can at some point. For now, I need to keep moving. Just wondering if 
others think it's a bug or not.

-Steve

Meta <jared771 gmail.com> writes:

On Friday, 22 November 2019 at 18:54:49 UTC, Steven Schveighoffer 
wrote:
 I have code in my proprietary project that looks like this:

 struct X
 {
    ...
    SQLStatement foo()
    {
       auto stmt = SQLStatement("`foo`"); // table
       return stmt.where("`id` = ?", id);
    }
 }

 where is a function that adds a where clause with a given value 
 to the SQL statement. It takes an SQLStatement by ref, and 
 returns that statement by ref.

 Signature looks like this:

 ref SQLStatement where(T)(return ref SQLStatement stmt, string 
 clause, T val)

 In this case, I'm using the convenience of returning the 
 statement to return that from the function.

 However, the compiler is complaining:

  Error: returning where(stmt, "`id` = ?", id) escapes a 
 reference to local variable stmt

 But... it's not returning a ref. So why the complaint?

 I have to separate into 2 lines.

 I tried to make a simple example to show the problem, but looks 
 like it doesn't fail in that case.

 Any ideas?

 -Steve

Are you passing the -dip1000 switch to the compiler? I reproduced 
this with a toy version of your code, but the compile error goes 
away when I pass the -dip1000 switch to the compiler.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 11/22/19 10:46 PM, Meta wrote:
 
 Are you passing the -dip1000 switch to the compiler? I reproduced this 
 with a toy version of your code, but the compile error goes away when I 
 pass the -dip1000 switch to the compiler.

I am not. But I admit that I didn't have the return attribute at first. 
I added it to see if it helped (it didn't).

Can you post the toy version? Might be reasonable for a bug report. I 
couldn't figure out a minimal case.

-Steve

Meta <jared771 gmail.com> writes:

On Saturday, 23 November 2019 at 04:20:33 UTC, Steven 
Schveighoffer wrote:
 On 11/22/19 10:46 PM, Meta wrote:
 
 Are you passing the -dip1000 switch to the compiler? I 
 reproduced this with a toy version of your code, but the 
 compile error goes away when I pass the -dip1000 switch to the 
 compiler.

 I am not. But I admit that I didn't have the return attribute 
 at first. I added it to see if it helped (it didn't).

 Can you post the toy version? Might be reasonable for a bug 
 report. I couldn't figure out a minimal case.

 -Steve

It's just your code ( safe added for good measure):

 safe:

struct SQLStatement
{
     string s;
}

struct X
{
    SQLStatement foo(int id)
    {
       auto stmt = SQLStatement("`foo`"); // table
       return stmt.where("`id` = ?", id);
    }
}

ref SQLStatement where(T)(return ref SQLStatement stmt, string 
clause, T val)
{
     return stmt;
}

void main()
{
     X x;
     x.foo(1);
}

This code fails to compile unless dip1000 is turned on.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 11/24/19 4:05 AM, Meta wrote:
 On Saturday, 23 November 2019 at 04:20:33 UTC, Steven Schveighoffer wrote:
 On 11/22/19 10:46 PM, Meta wrote:
 Are you passing the -dip1000 switch to the compiler? I reproduced 
 this with a toy version of your code, but the compile error goes away 
 when I pass the -dip1000 switch to the compiler.

 I am not. But I admit that I didn't have the return attribute at 
 first. I added it to see if it helped (it didn't).

 Can you post the toy version? Might be reasonable for a bug report. I 
 couldn't figure out a minimal case.

 -Steve

 
 It's just your code ( safe added for good measure):
 
  safe:
 
 struct SQLStatement
 {
      string s;
 }
 
 struct X
 {
     SQLStatement foo(int id)
     {
        auto stmt = SQLStatement("`foo`"); // table
        return stmt.where("`id` = ?", id);
     }
 }
 
 ref SQLStatement where(T)(return ref SQLStatement stmt, string clause, T 
 val)
 {
      return stmt;
 }
 
 void main()
 {
      X x;
      x.foo(1);
 }
 
 This code fails to compile unless dip1000 is turned on.
 
 

Oh my, I swear I put something similar into run.dlang.io and it compiled 
fine.

I'll file a bug.

-Steve

Steven Schveighoffer <schveiguy gmail.com> writes:

On 11/24/19 11:28 AM, Steven Schveighoffer wrote:

 
 Oh my, I swear I put something similar into run.dlang.io and it compiled 
 fine.
 
 I'll file a bug.

The key here is that SQLStatement has a string in it. In my toy test, I 
didn't put anything (or I just put an int maybe?)

Something about the pointer inside it makes a difference.

According to run.dlang.io, it's been broken since 2.072.3 or so. Going 
to file now...

-Steve

Walter Bright <newshound2 digitalmars.com> writes:

On 11/22/2019 10:54 AM, Steven Schveighoffer wrote:
 I have code in my proprietary project that looks like this:
 
 struct X
 {
     ...
     SQLStatement foo()
     {
        auto stmt = SQLStatement("`foo`"); // table
        return stmt.where("`id` = ?", id);
     }
 }
 
 where is a function that adds a where clause with a given value to the SQL 
 statement. It takes an SQLStatement by ref, and returns that statement by ref.
 
 Signature looks like this:
 
 ref SQLStatement where(T)(return ref SQLStatement stmt, string clause, T val)

   ^^^                       ^^^^^^^^^^

   Error: returning where(stmt, "`id` = ?", id) escapes a reference to local 
 variable stmt
 
 But... it's not returning a ref.

Yes it is. See the ^^^^

Steven Schveighoffer <schveiguy gmail.com> writes:

On 11/22/19 11:26 PM, Walter Bright wrote:
 On 11/22/2019 10:54 AM, Steven Schveighoffer wrote:
 I have code in my proprietary project that looks like this:

 struct X
 {
     ...
     SQLStatement foo()
     {
        auto stmt = SQLStatement("`foo`"); // table
        return stmt.where("`id` = ?", id);
     }
 }

 where is a function that adds a where clause with a given value to the 
 SQL statement. It takes an SQLStatement by ref, and returns that 
 statement by ref.

 Signature looks like this:

 ref SQLStatement where(T)(return ref SQLStatement stmt, string clause, 
 T val)

 
    ^^^                       ^^^^^^^^^^
 
   Error: returning where(stmt, "`id` = ?", id) escapes a reference to 
 local variable stmt

 But... it's not returning a ref.

 
 Yes it is. See the ^^^^

Yes, where is returning ref, but the complaint is not focused on that. 
It's saying returning the *result* of the where call is escaping the 
local. It's not. foo doesn't return ref.

If I split it into:

auto result = stmt.where("`id` = ?", id);
return result;

It works. This is what I'm expecting the compiler to do automatically.

I'll note that I was using inferred return types previously, and I 
thought maybe that was the problem. But here I have specified the return 
type exactly.

-Steve

Walter Bright <newshound2 digitalmars.com> writes:

On 11/23/2019 4:10 AM, Steven Schveighoffer wrote:
 It works. This is what I'm expecting the compiler to do automatically.

Ok, but you're going to need to find a test case that can be put on bugzilla.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 11/23/19 6:32 PM, Walter Bright wrote:
 On 11/23/2019 4:10 AM, Steven Schveighoffer wrote:
 It works. This is what I'm expecting the compiler to do automatically.

 
 Ok, but you're going to need to find a test case that can be put on 
 bugzilla.

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

-Steve

Walter Bright <newshound2 digitalmars.com> writes:

On 11/24/2019 8:52 AM, Steven Schveighoffer wrote:
 https://issues.dlang.org/show_bug.cgi?id=20416

Thank you.