www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6519] New: [CTFE] Problem with inout

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

           Summary: [CTFE] Problem with inout
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



D2 code:


inout(int[]) foo(inout int[] data) {
    return data;
}
void main() {
    enum int[] a = [1, 2];
    const r1 = foo(a); // OK
    enum r2 = foo(a); // Not OK
}



DMD 2.055beta gives:

test.d(7): Error: variable test2.main.r2 only fields, parameters or stack based
variables can be inout
test.d(7): Error: cannot evaluate foo([1,2]) at compile time

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 17 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6519


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au
            Summary|[CTFE] Problem with inout   |[CTFE] Problem with inout
                   |                            |and enum type inference



This is an enum bug, not a CTFE problem. Here's a reduced test case:

inout(int) foo(inout int data) {
    return data;
}

enum int e1 = foo(7); // OK
enum e1 = foo(7); // fails!

It thinks that you're trying to declare an enum of type 'inout(int)'.

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


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[CTFE] Problem with inout   |Problem with inout and type
                   |and enum type inference     |inference of polysemous
                   |                            |types



Here's an example which doesn't involve CTFE at all.

inout(int) foo(inout int data) {
    return 7;
}

void main()
{
    pragma(msg, typeof(foo(7)).stringof); // ---> inout(int)
}

The problem may be in expression.c, functionParameters().
If at parameter matches an inout parameter with implicit conversion, the inout
stays unresolved. That's necessary to allow things like:
foo(A, B)(inout(A) a, inout(B) b)

when B is int; it should work when A is immutable, and also when it is mutable.
But...
array literals are a problem. You can write:
int[] a = [1,2,3];
and also
immutable(int)[] b = [1,2,3];
In the first case, a sort of implicit .dup gets added.
Suppose we define 
     inout(int[]) foo(inout(int[]) x) { return x; }

Should the following compile?
   int[] x = foo([1,2,3]);
   immutable(int[]) y = foo([1,2,3]);
   const(int[]) z = foo([1,2,3]);

Currently only z compiles. The others say you cannot convert from inout(int[]) 
to int[].

One solution might be to say that if _all_ inout parameters are polysemous
value types, so that the return constness remains ambiguous, a tie-breaking
rule is applied to all of the parameters.
There are two reasonable options:
(a) always mutable. This would mean that x would compile, but z would stop
working in existing code. y would continue to be rejected.
That is, the type of foo([1,2,3]) would be typeof([1,2,3]).

(b) always const. No change to what compiles. This gives more efficient code,
since array literals don't need to be duped.

A third option would be that the return type propagates to the parameters.
Then, x, y, and z would all work, and we'd have perfect forwarding.
Implicit conversion of the return type of a call to such a function, would mean
implicit conversion of all the ambiguous parameters to such a function. Note
that this is recursive: a parameter of an inout function could itself be the
return value of another inout function.

This would be optimally efficient; there would never be an unnecessary implicit
.dup of array literals. It's a bit scary though -- I worry that that there
might be unintended consequences of such an idea.

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




I think this is a duplication of bug 3748.

With my patch (https://github.com/D-Programming-Language/dmd/pull/359), the




 Should the following compile?
    int[] x = foo([1,2,3]);
    immutable(int[]) y = foo([1,2,3]);
    const(int[]) z = foo([1,2,3]);


D's literals work like polysemous value, but basically they have mutable types.

static assert(is(typeof([1, 2]) == int[]));

Therefore typeof(foo([1, 2])) equals to int[], and only y shouldn't compile,
others should.

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE



*** This issue has been marked as a duplicate of issue 3748 ***

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