Jump to page: 1 2
Thread overview
[Issue 7105] New: relax inout rules
Dec 13, 2011
timon.gehr@gmx.ch
Feb 14, 2012
Stewart Gordon
Feb 14, 2012
timon.gehr@gmx.ch
Feb 14, 2012
Stewart Gordon
Feb 19, 2012
Kenji Hara
Feb 19, 2012
Kenji Hara
Feb 19, 2012
Kenji Hara
Feb 19, 2012
Stewart Gordon
Feb 19, 2012
Walter Bright
December 13, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7105

           Summary: relax inout rules
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: timon.gehr@gmx.ch


--- Comment #0 from timon.gehr@gmx.ch 2011-12-13 11:28:26 PST ---
Currently, DMD requires that the return type of a function that has inout-qualified parameters is itself qualified with inout. Removing this restriction would make the type system more expressive.

For example, the following function still requires code duplication to work for multiple differently qualified parameters:

void copy(int** tgt, int* src){ *tgt = src; }
void copy(immutable(int)** tgt, immutable(int)* src){ *tgt = src; }
void copy(const(int)** tgt, const(int)* src){ *tgt = src; }

With the lifted restriction, these three overloads can be merged:

void copy(inout(int)** tgt, inout(int)* src){ *tgt = src; }


Also see the newsgroup discussion on the topic: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=151839

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 14, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com


--- Comment #1 from Stewart Gordon <smjg@iname.com> 2012-02-14 11:25:40 PST ---
Another use case is to support foreach on a container of arbitrary constancy, by using

    int opApply(int delegate(ref inout(T)) dg) inout;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 14, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105



--- Comment #2 from timon.gehr@gmx.ch 2012-02-14 11:44:47 PST ---
That is an enhancement of what is suggested here. It is not very clear that inout should behave like that inside delegate/function pointer parameters. Maybe it is best if you open another enhancement request that discusses your design and its use cases in detail.

For example, what would be the meaning of the following declarations?

inout(int)[] delegate(inout(int)[] dg;
inout(int)[] foo(inout(int)[]delegate(inout(int)[] dg, inout(int)[] x){ ... }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 14, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105



--- Comment #3 from Stewart Gordon <smjg@iname.com> 2012-02-14 13:05:25 PST ---
(In reply to comment #2)
> For example, what would be the meaning of the following declarations?
> 
> inout(int)[] delegate(inout(int)[] dg;
> inout(int)[] foo(inout(int)[]delegate(inout(int)[] dg, inout(int)[] x){ ... }

Both of these would be syntax errors, because the brackets aren't matched.

But I see the ambiguity now.  Does the inout status belong to the delegate itself or to the function of which it is a parameter?

If the signature of dg is invalid because it doesn't pass the inout status through, then in principle it could be taken to belong to the outer function. Which would be passing the inout status through to the delegate rather than as a return.

I'll think about it and continue the discussion on the newsgroup.

Stewart.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 19, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #4 from Kenji Hara <k.hara.pg@gmail.com> 2012-02-18 23:48:12 PST ---
https://github.com/D-Programming-Language/dmd/pull/735

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 19, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105



--- Comment #5 from Kenji Hara <k.hara.pg@gmail.com> 2012-02-19 03:37:40 PST ---
(In reply to comment #1)
> Another use case is to support foreach on a container of arbitrary constancy, by using
> 
>     int opApply(int delegate(ref inout(T)) dg) inout;

I think that the inout parameter contravariant (I've filed as issue 7542) is necessary due to enable such signatures.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 19, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105



--- Comment #6 from Kenji Hara <k.hara.pg@gmail.com> 2012-02-19 03:55:08 PST ---
(In reply to comment #5)
> (In reply to comment #1)
> > Another use case is to support foreach on a container of arbitrary constancy, by using
> > 
> >     int opApply(int delegate(ref inout(T)) dg) inout;
> 
> I think that the inout parameter contravariant (I've filed as issue 7542) is necessary due to enable such signatures.

And I've posted issue 7543.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 19, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105



--- Comment #7 from Stewart Gordon <smjg@iname.com> 2012-02-19 06:37:31 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > For example, what would be the meaning of the following declarations?
> > 
> > inout(int)[] delegate(inout(int)[] dg;
> > inout(int)[] foo(inout(int)[]delegate(inout(int)[] dg, inout(int)[] x){ ... }
> 
> Both of these would be syntax errors, because the brackets aren't matched.
> 
> But I see the ambiguity now.  Does the inout status belong to the delegate itself or to the function of which it is a parameter?
> 
> If the signature of dg is invalid because it doesn't pass the inout status through, then in principle it could be taken to belong to the outer function. Which would be passing the inout status through to the delegate rather than as a return.
> 
> I'll think about it and continue the discussion on the newsgroup.

digitalmars.D
"inout and function/delegate parameters"

On web interface: http://forum.dlang.org/thread/jhr0t6$24v6$1@digitalmars.com

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 19, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105



--- Comment #8 from github-bugzilla@puremagic.com 2012-02-19 11:01:35 PST ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/98988d685d8fb16ebe05430c1dd8db5f799f1fe8 Merge pull request #735 from 9rnsr/fix7105

Issue 7105 - relax inout rules

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 19, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7105


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
« First   ‹ Prev
1 2