digitalmars.D.bugs - [Issue 7378] New: inout constructors do not properly resolve to immutable.
- d-bugmail puremagic.com (49/49) Jan 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7378
- d-bugmail puremagic.com (32/32) Jun 07 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7378
- d-bugmail puremagic.com (90/90) Jun 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7378
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
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
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