Bug 3748 – inout does not work properly

Status
RESOLVED
Resolution
FIXED
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2010-01-28T05:06:00Z
Last change time
2015-06-09T01:27:22Z
Keywords
patch
Assigned to
nobody
Creator
schveiguy
Blocks
1961

Attachments

IDFilenameSummaryContent-TypeSize
558testinout.dfile to test whether inout is properly implementedapplication/octet-stream2695
950testinout.dFixed some minor syntax error.application/octet-stream2703
1035testinout.dCorrected some errors that were previously hard to detect because inout didn't workapplication/octet-stream2707

Comments

Comment #0 by schveiguy — 2010-01-28T05:06:44Z
Created attachment 558 file to test whether inout is properly implemented inout as defined by DIP2 is not implemented properly on dmd 2.039. Attached is a testing program that should be used to determine if inout is properly implemented. I tried to include every subtle detail that I could on inout, but I'm not sure that I got them all. If the compiler passes this test, inout should be ready for most uses. Since half of the definition of inout is what *doesn't* compile, I have included multiple errors in the file. Because of the nature of compiler errors, each error can be individually enabled or disabled using version statements, a la error1, error2, etc. When no error statements are enabled, the program should compile correctly. There is no need to run the program, since all asserts are static.
Comment #1 by kennytm — 2011-04-26T11:20:36Z
Created attachment 950 Fixed some minor syntax error. Fixed the position of ';' on line 22. Added back the missing is() on lines 48 and 50. (Just a note: as of commit 48950d4ce371316184e2 (2.052) DMD still cannot compile this file successfully.)
Comment #2 by k.hara.pg — 2011-08-31T08:07:52Z
*** Issue 4968 has been marked as a duplicate of this issue. ***
Comment #3 by k.hara.pg — 2011-08-31T08:15:03Z
Comment #4 by k.hara.pg — 2011-08-31T10:40:24Z
My patch doesn't forbid to declare inout variable outside inout function. It is treated same as const variable, even with my patch. I think it is debatable thing.
Comment #5 by schveiguy — 2011-08-31T12:11:15Z
it is not debateable. The issue is, when inside an inout-enabled function, all inout variables are *assignable* from other inout variables. So for example, if you have: inout(int) * globalvar; inout(int)* foo(inout(int)* x) { return globalvar; } void main() { int x; auto y = foo(&x); } what type is y? inout(T) is changed to just T in this scenario, since the constancy factor is mutable, so essentially, you now have a mutable pointer to what is treated as const as you say. The type system *must* prevent non-local variables (i.e. variables not on the stack) from being inout. Otherwise, you cannot make guarantees about inout.
Comment #6 by bugzilla — 2011-10-01T22:10:12Z
Comment #7 by schveiguy — 2011-10-05T06:31:35Z
Created attachment 1035 Corrected some errors that were previously hard to detect because inout didn't work uploaded a fixed version of testinout.d error8 and error11 still compile, so this isn't completely resolved, but inout is definitely is usable. I will open a new bug for that, as this is a single problem with inout (allowing inout variables anywhere, not just as auto variables of inout functions). Note that Kenji stated those holes were still present. But this is definitely a huge step forward.
Comment #8 by schveiguy — 2011-10-05T06:49:38Z
See new bug 6770
Comment #9 by k.hara.pg — 2011-10-05T17:41:38Z
Comment #10 by k.hara.pg — 2011-12-12T03:05:17Z
*** Issue 6519 has been marked as a duplicate of this issue. ***
Comment #11 by k.hara.pg — 2011-12-12T03:07:07Z