www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Return by 'ref' problems...

reply Manu <turkeyman gmail.com> writes:
--00248c6a6a426cf32304bf31d810
Content-Type: text/plain; charset=UTF-8

So here's some problems.

I use 'const ref' to pass structs to functions (note: because 'in ref'
doesn't seem to work)
And I often need to return structs by ref too, but I'm having problems:

void test( const ref Thing x ) {} // this works fine. note, 'const ref'
works fine here (in lieu of 'in ref')


struct Thing { }
Thing thing;

const ref Thing func() { return gThing; }

This syntax complains, but it's precisely the same expression I use to pass
an argument in to a function, and it's fine there:
  remedy\modules\hud.d(35):Error: function remedy.hud.func without 'this'
cannot be const/immutable

const ref Thing function() blah = &func;

I need to take a pointer to this function, but It complains when I declare
a 'function' of this type:
  remedy\modules\hud.d(36):Error: variable remedy.hud.blah only parameters
or foreach declarations can be ref   (... what? it works for parameters?)


I try rearranging the syntax to make the first issue stop complaining:

ref const(Thing) func2() { return gThing; } // this seems to work now, but
i don't like the inconsistency...
ref const(Thing) function() blah2 = &func;

Error: variable remedy.hud.blah2 only parameters or foreach declarations
can be ref

--00248c6a6a426cf32304bf31d810
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So here&#39;s some problems.<div><br></div><div>I use &#39;const ref&#39; t=
o pass structs to functions (note: because &#39;in ref&#39; doesn&#39;t see=
m to work)</div><div>And I often need to return structs by ref too, but I&#=
39;m having problems:</div>
<div><br></div><div><div>void test(=C2=A0const ref Thing x ) {} //=C2=A0thi=
s works fine. note, &#39;const ref&#39; works fine here (in lieu of &#39;in=
 ref&#39;)</div><div><br></div><div><div><br></div><div>struct Thing { }</d=
iv><div>
Thing thing;</div><br class=3D"Apple-interchange-newline"></div><div>const =
ref Thing func() { return gThing; }</div><div><br></div><div><div>This synt=
ax complains, but it&#39;s precisely the same expression I use to pass an a=
rgument in to a function, and it&#39;s fine there:</div>
<div><div>=C2=A0 remedy\modules\hud.d(35):Error: function remedy.hud.func w=
ithout &#39;this&#39; cannot be const/immutable</div><br class=3D"Apple-int=
erchange-newline"></div></div><div>const ref Thing function() blah =3D &amp=
;func;</div>
<div><br></div><div>I need to take a pointer to this function, but It compl=
ains when I declare a &#39;function&#39; of this type:</div><div>=C2=A0 rem=
edy\modules\hud.d(36):Error: variable remedy.hud.blah only parameters or fo=
reach declarations can be ref =C2=A0 (... what? it works for parameters?)</=
div>
<div><br></div><div><br></div><div>I try rearranging the syntax to make the=
 first issue stop complaining:</div><div><br></div><div>ref const(Thing) fu=
nc2() { return gThing; } // this seems to work now, but i don&#39;t like th=
e inconsistency...</div>
<div>ref const(Thing) function() blah2 =3D &amp;func;</div></div><div><br><=
/div><div>Error: variable remedy.hud.blah2 only parameters or foreach decla=
rations can be ref</div>

--00248c6a6a426cf32304bf31d810--
May 04 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-04 10:38, Manu wrote:
 So here's some problems.

 I use 'const ref' to pass structs to functions (note: because 'in ref'
 doesn't seem to work)
 And I often need to return structs by ref too, but I'm having problems:

 void test( const ref Thing x ) {} // this works fine. note, 'const ref'
 works fine here (in lieu of 'in ref')


 struct Thing { }
 Thing thing;

 const ref Thing func() { return gThing; }

In this case the function "func" is declared const and not the return type. The reason for this is to allow this: class Foo { const: // All methods will be const } It's possible to do this with all attributes.
 This syntax complains, but it's precisely the same expression I use to
 pass an argument in to a function, and it's fine there:
    remedy\modules\hud.d(35):Error: function remedy.hud.func without
 'this' cannot be const/immutable

 const ref Thing function() blah = &func;

Again this declares the variable const and not the return type. I'm not sure about the "ref" thing. I don't know if function pointers can return by reference, at least not the syntax.
 I need to take a pointer to this function, but It complains when I
 declare a 'function' of this type:
    remedy\modules\hud.d(36):Error: variable remedy.hud.blah only
 parameters or foreach declarations can be ref   (... what? it works for
 parameters?)


 I try rearranging the syntax to make the first issue stop complaining:

 ref const(Thing) func2() { return gThing; } // this seems to work now,
 but i don't like the inconsistency...
 ref const(Thing) function() blah2 = &func;

This is the correct syntax to declare that it returns a const object.
 Error: variable remedy.hud.blah2 only parameters or foreach declarations
 can be ref

Don't know about the reference. -- /Jacob Carlborg
May 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-04 12:09, Manu wrote:

 Ah, of course! I didn't spot that >_<
 Thanks.

 I suppose technically, 'ref' can lead to the same ambiguity. This must
 be the core of the problem. ref needs to be supported with parentheses?

I'm not sure, since you can't declare a variable as "ref" I think the syntax should work. But the syntax with parentheses should probably work as well, to be consistent with "const". -- /Jacob Carlborg
May 04 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-04 14:27, Manu wrote:

 You can declare a variable as ref in the parameter list, that's where
 the ambiguity could arise, same with const.

Yes, but I thought this was a variable of some kind and not a parameter. -- /Jacob Carlborg
May 04 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30050eae9beacf04bf331d2e
Content-Type: text/plain; charset=UTF-8

On 4 May 2012 12:52, Jacob Carlborg <doob me.com> wrote:

 On 2012-05-04 10:38, Manu wrote:

 This syntax complains, but it's precisely the same expression I use to

pass an argument in to a function, and it's fine there:
   remedy\modules\hud.d(35):**Error: function remedy.hud.func without
 'this' cannot be const/immutable

 const ref Thing function() blah = &func;

Again this declares the variable const and not the return type. I'm not sure about the "ref" thing. I don't know if function pointers can return by reference, at least not the syntax.

Ah, of course! I didn't spot that >_< Thanks. I suppose technically, 'ref' can lead to the same ambiguity. This must be the core of the problem. ref needs to be supported with parentheses? --20cf30050eae9beacf04bf331d2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 4 May 2012 12:52, Jacob Carlborg <span dir=3D= "ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&= gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-05-04 10:38, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">This syntax complains, but it&#39;s precisel= y the same expression I use to</blockquote></div></blockquote><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> pass an argument in to a function, and it&#39;s fine there:<br> =C2=A0 remedy\modules\hud.d(35):<u></u>Error: function remedy.hud.func wit= hout<br> &#39;this&#39; cannot be const/immutable<br> <br> const ref Thing function() blah =3D &amp;func;<br> </blockquote> <br></div> Again this declares the variable const and not the return type. I&#39;m not= sure about the &quot;ref&quot; thing. I don&#39;t know if function pointer= s can return by reference, at least not the syntax.<br></blockquote><div> <br></div><div>Ah, of course! I didn&#39;t spot that &gt;_&lt;</div><div>Th= anks.</div><div><br></div><div>I suppose technically, &#39;ref&#39; can lea= d to the same ambiguity. This must be the core of the problem. ref needs to= be supported with parentheses?</div> </div> --20cf30050eae9beacf04bf331d2e--
May 04 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 4 May 2012 at 11:49:44 UTC, Jacob Carlborg wrote:
 On 2012-05-04 12:09, Manu wrote:

 Ah, of course! I didn't spot that >_<
 Thanks.

 I suppose technically, 'ref' can lead to the same ambiguity. 
 This must
 be the core of the problem. ref needs to be supported with 
 parentheses?

I'm not sure, since you can't declare a variable as "ref" I think the syntax should work. But the syntax with parentheses should probably work as well, to be consistent with "const".

Const can be used with parentheses because it is also a type qualifier in addition to a storage class (for syntactic purposes). All of const, immutable and shared have this dual syntactic existence. 'ref' has several meanings depending on context, but it is never a type qualifier. I think conflating the syntax for the two would mostly bring confusion.
May 04 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30050eaedf587e04bf35096a
Content-Type: text/plain; charset=UTF-8

On 4 May 2012 14:49, Jacob Carlborg <doob me.com> wrote:

 On 2012-05-04 12:09, Manu wrote:

  Ah, of course! I didn't spot that >_<
 Thanks.

 I suppose technically, 'ref' can lead to the same ambiguity. This must
 be the core of the problem. ref needs to be supported with parentheses?

I'm not sure, since you can't declare a variable as "ref" I think the syntax should work. But the syntax with parentheses should probably work as well, to be consistent with "const".

You can declare a variable as ref in the parameter list, that's where the ambiguity could arise, same with const. --20cf30050eaedf587e04bf35096a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 4 May 2012 14:49, Jacob Carlborg <span dir=3D= "ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&= gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-05-04 12:09, Manu wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Ah, of course! I didn&#39;t spot that &gt;_&lt;<br> Thanks.<br> <br> I suppose technically, &#39;ref&#39; can lead to the same ambiguity. This m= ust<br> be the core of the problem. ref needs to be supported with parentheses?<br> </blockquote> <br></div> I&#39;m not sure, since you can&#39;t declare a variable as &quot;ref&quot;= I think the syntax should work. But the syntax with parentheses should pro= bably work as well, to be consistent with &quot;const&quot;.</blockquote> <div><br></div><div>You can declare a variable as ref in the parameter list= , that&#39;s where the ambiguity could arise, same with const.</div></div> --20cf30050eaedf587e04bf35096a--
May 04 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/04/2012 10:38 AM, Manu wrote:
 So here's some problems.

 I use 'const ref' to pass structs to functions (note: because 'in ref'
 doesn't seem to work)
 And I often need to return structs by ref too, but I'm having problems:

 void test( const ref Thing x ) {} // this works fine. note, 'const ref'
 works fine here (in lieu of 'in ref')


 struct Thing { }
 Thing thing;

 const ref Thing func() { return gThing; }

 This syntax complains, but it's precisely the same expression I use to
 pass an argument in to a function, and it's fine there:
    remedy\modules\hud.d(35):Error: function remedy.hud.func without
 'this' cannot be const/immutable

 const ref Thing function() blah = &func;

It is not the same, because it is parsed like const{ ref Thing func() { return gThing; }
 I need to take a pointer to this function, but It complains when I
 declare a 'function' of this type:
    remedy\modules\hud.d(36):Error: variable remedy.hud.blah only
 parameters or foreach declarations can be ref   (... what? it works for
 parameters?)


 I try rearranging the syntax to make the first issue stop complaining:

 ref const(Thing) func2() { return gThing; } // this seems to work now,
 but i don't like the inconsistency...
 ref const(Thing) function() blah2 = &func;

 Error: variable remedy.hud.blah2 only parameters or foreach declarations
 can be ref

This is parsed like ref { const(Thing) function() blah2 = &func; } i.e. it qualifies the variable instead of the type. This should work: const(Thing) function()ref blah2 = &func; Except that it does not, because 'ref' is not currently a valid function 'storage class'. This seems to be an issue that deserves a bug report.
May 04 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/04/2012 03:00 PM, Jakob Ovrum wrote:
 On Friday, 4 May 2012 at 12:45:23 UTC, Timon Gehr wrote:
 This should work:

 const(Thing) function()ref blah2 = &func;

 Except that it does not, because 'ref' is not currently a valid
 function 'storage class'. This seems to be an issue that deserves a
 bug report.

For ref functions, 'ref' is part of the return type syntax,

If it was, then ref const(Thing) function() would work.
 much like auto functions.
 There is no precedent for 'ref' working as a function
 attribute; it never was one.

It is an attribute: int x; ref { int foo(){ return x; } int bar(){ return x; } } ref: int qux(){ return x; } static assert(typeof(&qux).stringof == "int function() ref");
May 04 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/04/2012 04:53 PM, Jakob Ovrum wrote:
 On Friday, 4 May 2012 at 14:34:20 UTC, Timon Gehr wrote:
 It is an attribute:

 int x;
 ref {
     int foo(){ return x; }
     int bar(){ return x; }
 }

 ref:

 int qux(){ return x; }

 static assert(typeof(&qux).stringof == "int function() ref");

Thanks, this is news to me! I never noticed that ref was actually a function attribute. The following are legal declaration statements: extern(C) void function() foo; pure void function() bar; // not just linkage attributes So I think it's a plain bug that this isn't: ref void function() foo;

What would be the meaning of void foo(ref void function() fn) { } ?
May 04 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-04 17:55, Jakob Ovrum wrote:
 On Friday, 4 May 2012 at 15:49:03 UTC, Manu wrote:
 It's very counter intuitive to mark the _function_ ref, rather than it's
 return type.

It is a function attribute, so it makes perfect sense. The rest is an issue of documentation/education. I agree it may not be optimally intuitive, but I don't see any superior syntactic options.

ref int a (); const int b (); const(int) c (); "a" is function returning an int by reference. "b" is a const function returning an int. "c" is a function returning a const int. Don't you see how it's confusing. Perhaps it would be better if "a" was declared like this: ref(int) a (); -- /Jacob Carlborg
May 04 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 4 May 2012 at 12:45:23 UTC, Timon Gehr wrote:
 This should work:

 const(Thing) function()ref blah2 = &func;

 Except that it does not, because 'ref' is not currently a valid 
 function 'storage class'. This seems to be an issue that 
 deserves a bug report.

For ref functions, 'ref' is part of the return type syntax, much like auto functions. There is no precedent for 'ref' working as a function attribute; it never was one.
May 04 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 4 May 2012 at 14:34:20 UTC, Timon Gehr wrote:
 It is an attribute:

 int x;
 ref {
   int foo(){ return x; }
   int bar(){ return x; }
 }

 ref:

 int qux(){ return x; }

 static assert(typeof(&qux).stringof == "int function() ref");

Thanks, this is news to me! I never noticed that ref was actually a function attribute. The following are legal declaration statements: extern(C) void function() foo; pure void function() bar; // not just linkage attributes So I think it's a plain bug that this isn't: ref void function() foo;
May 04 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 4 May 2012 at 14:57:14 UTC, Timon Gehr wrote:
 What would be the meaning of

 void foo(ref void function() fn) { }

 ?

Parameter storage classes can only go before the type, while function attributes can also go after the parameter list (of the function pointer or delegate for this case). So I would think that: void foo(ref void function() fn) { } The above 'foo' would receive a function pointer by reference, while: void foo(void function() ref fn) { } Would receive a function pointer which returns by ref.
May 04 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3005dc105729a304bf37dbc4
Content-Type: text/plain; charset=UTF-8

On 4 May 2012 18:07, Jakob Ovrum <jakobovrum gmail.com> wrote:

 On Friday, 4 May 2012 at 14:57:14 UTC, Timon Gehr wrote:

 What would be the meaning of

 void foo(ref void function() fn) { }

 ?

Parameter storage classes can only go before the type, while function attributes can also go after the parameter list (of the function pointer or delegate for this case). So I would think that: void foo(ref void function() fn) { } The above 'foo' would receive a function pointer by reference, while: void foo(void function() ref fn) { } Would receive a function pointer which returns by ref.

It's very counter intuitive to mark the _function_ ref, rather than it's return type. --20cf3005dc105729a304bf37dbc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 4 May 2012 18:07, Jakob Ovrum <span dir=3D"lt= r">&lt;<a href=3D"mailto:jakobovrum gmail.com" target=3D"_blank">jakobovrum= gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, 4 May 2012 at 14:57:14 UTC, Timon Gehr wrote:<= br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> What would be the meaning of<br> <br> void foo(ref void function() fn) { }<br> <br> ?<br> </blockquote> <br></div> Parameter storage classes can only go before the type, while function attri= butes can also go after the parameter list (of the function pointer or dele= gate for this case). So I would think that:<div class=3D"im"><br> <br> =C2=A0 =C2=A0void foo(ref void function() fn) { }<br> <br></div> The above &#39;foo&#39; would receive a function pointer by reference, whil= e:<br> <br> =C2=A0 =C2=A0void foo(void function() ref fn) { }<br> <br> Would receive a function pointer which returns by ref.<br> </blockquote></div><br><div>It&#39;s very counter intuitive to mark the _fu= nction_ ref, rather than it&#39;s return type.</div> --20cf3005dc105729a304bf37dbc4--
May 04 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 4 May 2012 at 15:49:03 UTC, Manu wrote:
 It's very counter intuitive to mark the _function_ ref, rather 
 than it's
 return type.

It is a function attribute, so it makes perfect sense. The rest is an issue of documentation/education. I agree it may not be optimally intuitive, but I don't see any superior syntactic options.
May 04 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3005dc10d0e16704bf38255e
Content-Type: text/plain; charset=UTF-8

On 4 May 2012 18:55, Jakob Ovrum <jakobovrum gmail.com> wrote:

 On Friday, 4 May 2012 at 15:49:03 UTC, Manu wrote:

 It's very counter intuitive to mark the _function_ ref, rather than it's
 return type.

It is a function attribute, so it makes perfect sense. The rest is an issue of documentation/education. I agree it may not be optimally intuitive, but I don't see any superior syntactic options.

Well, I personally see no reason not to allow 'ref' variables anywhere, just like in C++. Breaking out pointers in D feels a bit dirty, by the same reasoning that you use C++ references. Why not make it a type modifier? It would just be a guaranteed initialised pointer like in C++, and with no pointer assignment semantics. --20cf3005dc10d0e16704bf38255e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 4 May 2012 18:55, Jakob Ovrum <span dir=3D"lt= r">&lt;<a href=3D"mailto:jakobovrum gmail.com" target=3D"_blank">jakobovrum= gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, 4 May 2012 at 15:49:03 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> It&#39;s very counter intuitive to mark the _function_ ref, rather than it&= #39;s<br> return type.<br> </blockquote> <br></div> It is a function attribute, so it makes perfect sense. The rest is an issue= of documentation/education.<br> <br> I agree it may not be optimally intuitive, but I don&#39;t see any superior= syntactic options.<br> </blockquote></div><br><div>Well, I personally see no reason not to allow &= #39;ref&#39; variables anywhere, just like in C++. Breaking out pointers in= D feels a bit dirty, by the same reasoning that you use C++ references.</d= iv> <div>Why not make it a type modifier? It would just be a guaranteed initial= ised pointer like in C++, and with no pointer assignment semantics.</div> --20cf3005dc10d0e16704bf38255e--
May 04 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 4 May 2012 at 20:00:10 UTC, Jacob Carlborg wrote:
 ref int a ();
 const int b ();
 const(int) c ();

I fully understand the difference, it's a common source of confusion. But it also makes perfect sense if you know the rules about function attributes. I don't think it's optimal, but changing it now would break a lot of code, it cannot happen for D2. The best we can do is make 'ref' work properly as a function attribute by allowing it to occur after the parameter list. 'inout' also has this problem, but opposite; sometimes putting it in front of the member function makes it behave differently. I can't remember if there is a bug report for it (probably is... or maybe not, because nobody even expected inout to work at all a couple of versions ago).
 Perhaps it would be better if "a" was declared like this:

 ref(int) a ();

ref is not a type qualifier, I think that would be even more confusing. It would be completely out of sync with the rest of the language.
May 04 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--f46d0442811e9b89c204bf3e4ccd
Content-Type: text/plain; charset=UTF-8

On 4 May 2012 23:16, Jakob Ovrum <jakobovrum gmail.com> wrote:

 Perhaps it would be better if "a" was declared like this:
 ref(int) a ();

ref is not a type qualifier, I think that would be even more confusing. It would be completely out of sync with the rest of the language.

But maybe it should be, then you'd be able to declare ref variables anywhere, like in C++... what's the disadvantage of that? --f46d0442811e9b89c204bf3e4ccd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 4 May 2012 23:16, = Jakob Ovrum <span dir=3D"ltr">&lt;<a href=3D"mailto:jakobovrum gmail.com" t= arget=3D"_blank">jakobovrum gmail.com</a>&gt;</span> wrote:<br><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid= ;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">Perhaps it would be better= if &quot;a&quot; was declared like this:<br> <br> ref(int) a ();<br> </blockquote> <br></div> ref is not a type qualifier, I think that would be even more confusing. It = would be completely out of sync with the rest of the language.<br></blockqu= ote><div><br></div><div>But maybe it should be, then you&#39;d be able to d= eclare ref variables anywhere, like in C++... what&#39;s the disadvantage o= f that?</div> </div></div> --f46d0442811e9b89c204bf3e4ccd--
May 04 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, May 05, 2012 02:30:00 Manu wrote:
 On 4 May 2012 23:16, Jakob Ovrum <jakobovrum gmail.com> wrote:
 Perhaps it would be better if "a" was declared like this:
 ref(int) a ();

ref is not a type qualifier, I think that would be even more confusing. It would be completely out of sync with the rest of the language.

But maybe it should be, then you'd be able to declare ref variables anywhere, like in C++... what's the disadvantage of that?

I know that Walter's against it, but unfortunately, I don't recall his arguments. But I'd certainly be very surprised if it ever happened. - Jonathan M Davis
May 04 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074d4fe7a883704bf3ef389
Content-Type: text/plain; charset=UTF-8

On 5 May 2012 02:38, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Saturday, May 05, 2012 02:30:00 Manu wrote:
 On 4 May 2012 23:16, Jakob Ovrum <jakobovrum gmail.com> wrote:
 Perhaps it would be better if "a" was declared like this:
 ref(int) a ();

ref is not a type qualifier, I think that would be even more


 would be completely out of sync with the rest of the language.

But maybe it should be, then you'd be able to declare ref variables anywhere, like in C++... what's the disadvantage of that?

I know that Walter's against it, but unfortunately, I don't recall his arguments. But I'd certainly be very surprised if it ever happened.

Yes, I get that impression also. But it seems strange, it would automatically solve these problems, and as a handy bonus, it would be useful in lots of other situations! :) --20cf3074d4fe7a883704bf3ef389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 5 May 2012 02:38, = Jonathan M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.co= m" target=3D"_blank">jmdavisProg gmx.com</a>&gt;</span> wrote:<br><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Saturday, May 05, 2012 02:30:00 = Manu wrote:<br> &gt; On 4 May 2012 23:16, Jakob Ovrum &lt;<a href=3D"mailto:jakobovrum gmai= l.com">jakobovrum gmail.com</a>&gt; wrote:<br> &gt; &gt; Perhaps it would be better if &quot;a&quot; was declared like thi= s:<br> &gt; &gt;&gt; ref(int) a ();<br> &gt; &gt;<br> &gt; &gt; ref is not a type qualifier, I think that would be even more conf= using. It<br> &gt; &gt; would be completely out of sync with the rest of the language.<br=

&gt; But maybe it should be, then you&#39;d be able to declare ref variable= s<br> &gt; anywhere, like in C++... what&#39;s the disadvantage of that?<br> <br> </div></div>I know that Walter&#39;s against it, but unfortunately, I don&#= 39;t recall his<br> arguments. But I&#39;d certainly be very surprised if it ever happened.<br>= </blockquote><div><br></div><div>Yes, I get that impression also. But it se= ems strange, it would automatically solve these problems, and as a handy bo= nus, it would be useful in lots of other situations! :)</div> </div></div> --20cf3074d4fe7a883704bf3ef389--
May 04 2012
prev sibling next sibling parent "Remo" <remotion4d googlemail.com> writes:
Hi,

are there any news about this problem ?

This code does compile.
[code]
ref int min(ref int lhs,ref int rhs) {
	return lhs > rhs ? rhs : lhs;
}
auto fptr = &min;

pragma(msg,typeof(fptr).stringof);  //int function(ref int lhs, 
ref int rhs) ref
[/code]

But how to manually specify type of fptr?

This does not compiles
[code]
int function(ref int lhs, ref int rhs) ref  fptr3 = &min; 
//Error:  no identifier for declarator int function(ref int lhs, 
ref int rhs)
[/code]

this one too.
[code]
ref int function(ref int lhs, ref int rhs)   fptr3 = &min; 
//Error: only parameters or foreach declarations can be ref
[/code]

Right now I am using dmd.2.065.0-rc1.
Feb 19 2014
prev sibling next sibling parent "Remo" <remotion4d googlemail.com> writes:
Hm [code] does not work.

Any way here is the test code.
http://melpon.org/wandbox/permlink/ZDz42rynoTaK1P4o


On Wednesday, 19 February 2014 at 16:20:39 UTC, Remo wrote:
 Hi,

 are there any news about this problem ?

 This code does compile.
 [code]
 ref int min(ref int lhs,ref int rhs) {
 	return lhs > rhs ? rhs : lhs;
 }
 auto fptr = &min;

 pragma(msg,typeof(fptr).stringof);  //int function(ref int lhs, 
 ref int rhs) ref
 [/code]

 But how to manually specify type of fptr?

 This does not compiles
 [code]
 int function(ref int lhs, ref int rhs) ref  fptr3 = &min; 
 //Error:  no identifier for declarator int function(ref int 
 lhs, ref int rhs)
 [/code]

 this one too.
 [code]
 ref int function(ref int lhs, ref int rhs)   fptr3 = &min; 
 //Error: only parameters or foreach declarations can be ref
 [/code]

 Right now I am using dmd.2.065.0-rc1.

Feb 19 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 19 February 2014 at 16:20:39 UTC, Remo wrote:
 Hi,

 are there any news about this problem ?

 This code does compile.
 [code]
 ref int min(ref int lhs,ref int rhs) {
 	return lhs > rhs ? rhs : lhs;
 }
 auto fptr = &min;

 pragma(msg,typeof(fptr).stringof);  //int function(ref int lhs, 
 ref int rhs) ref
 [/code]

 But how to manually specify type of fptr?

 This does not compiles
 [code]
 int function(ref int lhs, ref int rhs) ref  fptr3 = &min; 
 //Error:  no identifier for declarator int function(ref int 
 lhs, ref int rhs)
 [/code]

 this one too.
 [code]
 ref int function(ref int lhs, ref int rhs)   fptr3 = &min; 
 //Error: only parameters or foreach declarations can be ref
 [/code]

 Right now I am using dmd.2.065.0-rc1.

Looks like it's a bug. A workaround is: typeof(&min) fprt = &min; Or just use auto like in your example above.
Feb 19 2014
prev sibling next sibling parent "Remo" <remotion4d googlemail.com> writes:
 Looks like it's a bug.

It is not possible to use auto because in real code the functions are extern(C).
 A workaround is: typeof(&min) fprt = &min;

this way. private ref int __hidden_fn_1002(ref int lhs,ref int rhs); typeof(&__hidden_fn_1002) fprt; Is there a way to make this much shorter? Something like this ? typeof(& (ref int __hidden_fn_1002(ref int lhs,ref int rhs))) fprt; On Wednesday, 19 February 2014 at 16:47:08 UTC, Meta wrote:
 On Wednesday, 19 February 2014 at 16:20:39 UTC, Remo wrote:
 Hi,

 are there any news about this problem ?

 This code does compile.
 [code]
 ref int min(ref int lhs,ref int rhs) {
 	return lhs > rhs ? rhs : lhs;
 }
 auto fptr = &min;

 pragma(msg,typeof(fptr).stringof);  //int function(ref int 
 lhs, ref int rhs) ref
 [/code]

 But how to manually specify type of fptr?

 This does not compiles
 [code]
 int function(ref int lhs, ref int rhs) ref  fptr3 = &min; 
 //Error:  no identifier for declarator int function(ref int 
 lhs, ref int rhs)
 [/code]

 this one too.
 [code]
 ref int function(ref int lhs, ref int rhs)   fptr3 = &min; 
 //Error: only parameters or foreach declarations can be ref
 [/code]

 Right now I am using dmd.2.065.0-rc1.

Looks like it's a bug. A workaround is: typeof(&min) fprt = &min; Or just use auto like in your example above.

Feb 19 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 19 February 2014 at 17:01:15 UTC, Remo wrote:
 Looks like it's a bug.

It is not possible to use auto because in real code the functions are extern(C).

Perhaps I'm missing something, but auto isn't incompatible with extern(C)
Feb 19 2014
prev sibling next sibling parent "Remo" <remotion4d googlemail.com> writes:
 Perhaps I'm missing something, but auto isn't incompatible with 
 extern(C)

What I mean is that I only need to define function pointer to a function. The function it self is extern and is a C++/C function.
Feb 19 2014
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 02/19/14 17:20, Remo wrote:
 
 This code does compile.
 [code]
 ref int min(ref int lhs,ref int rhs) {
     return lhs > rhs ? rhs : lhs;
 }
 auto fptr = &min;
 
 pragma(msg,typeof(fptr).stringof);  //int function(ref int lhs, ref int rhs)
ref
 [/code]
 
 But how to manually specify type of fptr?
 
 This does not compiles
 [code]
 int function(ref int lhs, ref int rhs) ref  fptr3 = &min; //Error:  no
identifier for declarator int function(ref int lhs, ref int rhs)
 [/code]
 
 this one too.
 [code]
 ref int function(ref int lhs, ref int rhs)   fptr3 = &min; //Error: only
parameters or foreach declarations can be ref
 [/code]

alias extern(C) ref int function(ref int lhs, ref int rhs) Ftype; Ftype fprt; artur
Feb 19 2014
prev sibling next sibling parent "Remo" <remotion4d googlemail.com> writes:
Excellent, this way is much better.

Thanks you artur.

On Wednesday, 19 February 2014 at 19:55:30 UTC, Artur Skawina 
wrote:
 On 02/19/14 17:20, Remo wrote:
 
 This code does compile.
 [code]
 ref int min(ref int lhs,ref int rhs) {
     return lhs > rhs ? rhs : lhs;
 }
 auto fptr = &min;
 
 pragma(msg,typeof(fptr).stringof);  //int function(ref int 
 lhs, ref int rhs) ref
 [/code]
 
 But how to manually specify type of fptr?
 
 This does not compiles
 [code]
 int function(ref int lhs, ref int rhs) ref  fptr3 = &min; 
 //Error:  no identifier for declarator int function(ref int 
 lhs, ref int rhs)
 [/code]
 
 this one too.
 [code]
 ref int function(ref int lhs, ref int rhs)   fptr3 = &min; 
 //Error: only parameters or foreach declarations can be ref
 [/code]

alias extern(C) ref int function(ref int lhs, ref int rhs) Ftype; Ftype fprt; artur

Feb 19 2014
prev sibling parent Jerry <jlquinn optonline.net> writes:
"Remo" <remotion4d googlemail.com> writes:

 Looks like it's a bug.


https://d.puremagic.com/issues/
Feb 19 2014