Bug 8400 – static array type cannot interpret dynamic array length

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-07-18T15:56:00Z
Last change time
2013-06-01T00:59:57Z
Keywords
pull, rejects-valid
Assigned to
nobody
Creator
timon.gehr
Blocks
8312

Comments

Comment #0 by timon.gehr — 2012-07-18T15:56:56Z
DMD 2.059: void main(){ immutable a = [1,2]; int[a.length+0] b; // ok int[a.length ] c; // error } The code should compile.
Comment #1 by k.hara.pg — 2012-07-19T08:49:18Z
Comment #2 by github-bugzilla — 2012-07-19T23:53:42Z
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b4b6211c519cc744c83e2985fcfaafe68c0fad19 fix Issue 8400 - static array type cannot interpret dynamic array length Local variables always should be interpreted to detect whether it is really constant expression or not. https://github.com/D-Programming-Language/dmd/commit/0dad66820b826d4ee55a82f0a692548c5bd511af Merge pull request #1058 from 9rnsr/fix8400 Issue 8400 - static array type cannot interpret dynamic array length
Comment #3 by bearophile_hugs — 2012-07-23T08:47:04Z
> void main(){ > immutable a = [1,2]; > int[a.length+0] b; // ok > int[a.length ] c; // error > } > > The code should compile. That code should not compile, in my opinion. Nor this one: immutable a = [1, 2]; void main() { int[a.length] b; } See some discussion: http://forum.dlang.org/thread/[email protected]
Comment #4 by clugdbug — 2012-07-25T03:39:21Z
(In reply to comment #3) > > void main(){ > > immutable a = [1,2]; > > int[a.length+0] b; // ok > > int[a.length ] c; // error > > } > > > > The code should compile. > > That code should not compile, in my opinion. The rule is, in any circumstance where a compile-time value is required, it will attempt to interpret it at compile time. If it fails, it is an error. > Nor this one: > > immutable a = [1, 2]; > void main() { > int[a.length] b; > } No, that should *definitely* compile. Global variables with initializers always have the initializer CTFE'd.
Comment #5 by bearophile_hugs — 2012-07-25T07:19:15Z
(In reply to comment #4) > > That code should not compile, in my opinion. > > The rule is, in any circumstance where a compile-time value is required, it > will attempt to interpret it at compile time. If it fails, it is an error. I am not sure, but I think you are agreeing with me, so I mark this as a regression. > Global variables with initializers always have the initializer CTFE'd. OK.
Comment #6 by k.hara.pg — 2012-07-25T08:36:03Z
bearophile's marking as 'regression' is invalid. My explanation is here: http://d.puremagic.com/issues/show_bug.cgi?id=8312#c5 Then I revert the importance to 'normal', and mark as 'resolved fixed'.
Comment #7 by clugdbug — 2012-07-26T01:35:52Z
(In reply to comment #5) > (In reply to comment #4) > > > > That code should not compile, in my opinion. > > > > The rule is, in any circumstance where a compile-time value is required, it > > will attempt to interpret it at compile time. If it fails, it is an error. > > I am not sure, but I think you are agreeing with me, so I mark this as a > regression. I was disagreeing with you.
Comment #8 by github-bugzilla — 2013-06-01T00:59:57Z
Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/50569d88e7b0ccf8d786b65bf4f0321fd2698fd2 CTFE: Don't save local variables in the global constants list Even if they are immutable local variables (eg, bug 8400)