[Issue 7378] inout constructors do not properly resolve to immutable.

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Jun 10 08:44:35 PDT 2013


http://d.puremagic.com/issues/show_bug.cgi?id=7378


Steven Schveighoffer <schveiguy at yahoo.com> changed:

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


--- Comment #2 from Steven Schveighoffer <schveiguy at yahoo.com> 2013-06-10 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: -------


More information about the Digitalmars-d-bugs mailing list