www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7378] New: inout constructors do not properly resolve to immutable.

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

           Summary: inout constructors do not properly resolve to
                    immutable.
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: schveiguy yahoo.com



06:44:10 PST ---
The following code:

import std.stdio;

struct T
{
  int *data;
  this(inout(int)* d) inout {this.data = d;}
}

void main()
{
  int x;
  const int xc;
  immutable int xi;

  writeln(typeof(T(&x)).stringof);
  writeln(typeof(T(&xc)).stringof);
  writeln(typeof(T(&xi)).stringof);
}

outputs:

T
const(T)
const(T)

It should output:

T
const(T)
immutable(T)

I suspect the issue is that the constructor's this pointer is being treated as
a parameter instead of the result, and it's implicitly declared as mutable.  If
you consider that in a constructor, the return value is a newly constructed T
struct, the 'this' parameter is semantically the return value.

So what should happen is the inout resolution mechanism should treat the
parameters to the constructor as the only parameters, and the implicit this
parameter as the return value.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 27 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7378


Maksim Zholudev <maximzms gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |maximzms gmail.com
         Resolution|                            |FIXED



PDT ---
Since this pull request was merged
https://github.com/D-Programming-Language/dmd/pull/1726
one must specify the qualifier explicitly:
--------------------
import std.stdio;

struct T
{
  int *data;
  this(inout(int)* d) inout {this.data = d;}
}

void main()
{
  int x;
  const int xc;
  immutable int xi;

  writeln(typeof(T(&x)).stringof);
  writeln(typeof(const T(&xc)).stringof);
  writeln(typeof(immutable T(&xi)).stringof);
}
--------------------
So now inout constructors are resolved manually.

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


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |k.hara.pg gmail.com
         Resolution|FIXED                       |
           Severity|normal                      |enhancement



08:44:33 PDT ---
Reopening, I don't agree with the pulled request.

An inout function has to have a return value based on the input values.  This
pull is for some reason *requiring* you to dictate what the return type should
be, when it's clear from the parameters.

Look at the following function:

inout(int) *foo(inout int *x, inout int *y)
{
   return *x < *y ? x : y;
}

int x;
immutable int ix;

We have inout on the return value, inout on the parameters.  The return value's
inout is dictated by the parameters, it's not dictated manually.  You don't
write (or have to write):

const foo(&x, &ix);

You just write:

foo(&x, &ix);

And the return value is dictated by the parameters (as const(int) *).

But if we look at the patch, it requires the verbose redundant form.  In this
case, inout is not doing what it was meant to do, it's a manually-defined
wildcard.  And then YOU have to fulfill the promise with the parameters you
pass in.  While dictating the return type might be a valid use case, it's not
the only use case, and significantly diminishes the value of inout.

I postulate that the constructor call is simply another function call, and that
T() doesn't correspond to "the return type is mutable T", it corresponds to
"call T's constructor and let it dictate what to return, based on the
parameters".

In other words, the function attribute is a property of the RETURN type, not
the 'this' parameter.  In actuality, the 'this' parameter is a 'unique' type,
readily changeable into inout/const/immutable/whatever because it's simply raw
data that hasn't yet been referenced.  The semantics inside the function follow
that (members are mutable even though 'this' is inout).

The newly pulled patch makes this overly restrictive.  There is no reason to
require that immutable be specified on the constructor call, when the only
possible valid type modifier is immutable.  Inout is supposed to alleviate that
requirement.

I look at a constructor like this:

this(inout(int) *_x) inout
{
    ...
}

To be interpreted in the compiler like this:

inout(T) __ctor(inout(int) *_x)
{
   unique(inout(T)) this; // unique is defined as 'head-mutable until read'
   ...
   return this;
}

My expectation is for:

auto t1 = T(&ix); // type of t1 is immutable(T)
auto t2 = T(&x); // type of t2 is T
auto t3 = const T(&ix); // type of t3 is const(T) (ok to cast immutable(T) to
const(T) )
auto t4 = immutable T(&ix); // type of t4 is immutable(T) (equivalent to t1
case)
const t5 = T(&ix); // type of t5 is const(T)
const t6 = immutable T(&ix); // type of t6 is const(T)

// failing calls
auto f1 = immutable T(&x); // error, cannot cast T to immutable(T) implicitly
immutable f2 = T(&x); // same thing
immutable f3 = const T(&cx); // error cannot cast const(T) to immutable(T)
implicitly
T f4 = T(&ix) // error, cannot cast immutable(T) to T

From Kenji's pull request:

S([1, 2, 3].idup)

should compile, and return an immutable(S).  It then cannot be assigned to a
mutable S, and that is fine.

For what it's worth, I also think this should be the case for non-inout
constructors:

struct T
{
   int *x;
   this(int *_x) { x = _x;}
   this(immutable(int) *_x) immutable { x = _x;}
}

immutable int ix;

auto t = T(&ix); // typeof(t) == immutable(T)

CC'ing kenji so he is aware of this view and can agree/disagree/clarify.

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