www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2753] New: Cannot declare pointer to function returning ref

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753

           Summary: Cannot declare pointer to function returning ref
           Product: D
           Version: 2.025
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: jlquinn optonline.net


ref int c() { static int a=2; return a; }
ref int function() d = &c; // line 8

foo.d(8): variable foo.d only parameters or foreach declarations can be ref

Type inference, however, is able to figure it out:

ref int c() { static int a=2; return a; }
auto d = &c; // whee

Correctly reporting the issue from bug 2735


--
Mar 21 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com
           Keywords|                            |spec




------- Comment #1 from smjg iname.com  2009-03-21 17:34 -------
The problem seems to be an ambiguity in the grammar: is it ref (int function())
or (ref int) function()?

Maybe we need a bracket notation for ref like we have for const and invariant.

Note that, if we have both this and the notation proposed in bug 1961, ref and
inout would no longer be synonyms.


--
Mar 21 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753





------- Comment #2 from maxmo pochta.ru  2009-03-22 03:00 -------
judging from compiler error messages, ref is not a type modifier, it's a
function attribute, so brackets won't help. It should also be noted, that
others function attributes' grammar is also ambiguous.
---
nothrow int function() foo();
---
What is nothrow here?

---
const int foo();
---
What is const here?

---
int foo(ref int function() goo);
---
This one would probably give no error.

Is it keyword saving issue? Semantically different things have the same syntax.
If Walter wants context-dependent keywords, he should mark those contexts
better.
I would like to see function attributes at predictable, easy-to-spot locations,
so it would be no chanse to mess storage class with function attributes. There
are already good places for function attributes (after function) and storage
class attributes (before type). If the attributes will be restricted to
corresponding places, there will be no ambiguity (except const).
---
int foo(ref int function() goo); //ref parameter
int goo(int function() ref foo); //return byref function
---


--
Mar 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753





------- Comment #3 from smjg iname.com  2009-03-22 16:50 -------
(In reply to comment #2)

 judging from compiler error messages, ref is not a type modifier, it's a
 function attribute, so brackets won't help. 



I'm a little confused - if that were the case, surely it would work?

Moreover, what is there preventing ref from becoming a type modifier, if this
would fix the problem?

It should also be noted, that

 others function attributes' grammar is also ambiguous.
 ---
 nothrow int function() foo();
 ---
 What is nothrow here?



So there's actually an advantage to the suffix notation for function
attributes.


 ---
 const int foo();
 ---
 What is const here?
 
 ---
 int foo(ref int function() goo);
 ---
 This one would probably give no error.



But that is a case that really is ambiguous.


 Is it keyword saving issue? Semantically different things have the same syntax.
 If Walter wants context-dependent keywords, he should mark those contexts
 better.
 I would like to see function attributes at predictable, easy-to-spot locations,
 so it would be no chanse to mess storage class with function attributes. There
 are already good places for function attributes (after function) and storage
 class attributes (before type). If the attributes will be restricted to
 corresponding places, there will be no ambiguity (except const).
 ---
 int foo(ref int function() goo); //ref parameter
 int goo(int function() ref foo); //return byref function
 ---



I don't really like this.  The ref essentially means the same thing, it's just
whether it applies to the parameter or the return.  In the latter, it's being
moved further from what it applies to: the return type.

IIRC, the equivalent C++ syntax is

int foo(int (*&goo)());  // ref parameter
int goo(int& (*foo)());  // ref return in parameter

It isn't exactly clear, but at least it's unambiguous.  If D got the & notation
for reference, we would have

int foo(int function()& goo);  // ref parameter
int goo(int& function() foo);  // ref return in parameter

Indeed, we could have ref take the place of & in this notation

int foo(int function() ref goo);  // ref parameter
int goo(int ref function() foo);  // ref return in parameter

and so the syntax of ref/& would become consistent with that of *.

We could do it like this, or we could make ref a type modifier along the lines
of const.  Take your pick.


--
Mar 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753





------- Comment #4 from maxmo pochta.ru  2009-03-24 04:17 -------
(In reply to comment #3)

 int foo(int function() ref goo);  // ref parameter
 int goo(int ref function() foo);  // ref return in parameter



attributes... interesting...


--
Mar 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753





------- Comment #5 from smjg iname.com  2009-03-24 04:26 -------
(In reply to comment #4)

 (In reply to comment #3)

 int foo(int function() ref goo);  // ref parameter
 int goo(int ref function() foo);  // ref return in parameter



 attributes... interesting...



Any particular reason you feel it still has to count as a function attribute?


--
Mar 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753





------- Comment #6 from maxmo pochta.ru  2009-03-26 03:46 -------
1) if it can why not?
2) this is usable for other function attributes


--
Mar 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eatingstaples gmail.com


--- Comment #7 from yebblies <yebblies gmail.com> 2011-06-06 19:46:53 PDT ---
*** Issue 5421 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 06 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2753


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr gmx.ch


--- Comment #8 from yebblies <yebblies gmail.com> 2011-06-06 21:26:33 PDT ---
*** Issue 5828 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 06 2011