| |
 | Posted by Steven Schveighoffer
in reply to Steven Schveighoffer |  Permalink Reply |
|
Steven Schveighoffer 
| 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
--- Comment #2 from Steven Schveighoffer <schveiguy@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: -------
|
