https://issues.dlang.org/show_bug.cgi?id=7492
Denis Shelomovskij <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |INVALID --- Comment #10 from Denis Shelomovskij <[email protected]> --- (In reply to Steven Schveighoffer from comment #9) > (In reply to Denis Shelomovskij from comment #8) > > > So I'm for marking this one as INVALID and for fixing Issue 14017. > > I disagree completely. CTFE is a special case, and should be treated > specially. There are many cases where a function can be used as CTFE in some > cases, and some cases it cannot. One of those requirements is that it is > effectively pure. Given that CTFE functions MUST provide all source, they > should be able to be inferred pure, with all the benefits that entails. > > I think the issue here is not the function, but what you can do with the > return value. In your example, both calls return a mutable int[]. It's just > that the compiler can prove due to CTFE that it is unique and has free reign > to convert to any constancy required. Nobody argues the function IS effectively `pure` in CTFE contexts. The problem is in introduction of a new language type system rule. Anyway this issue is INVALID and for such enhancement I opened Issue 14018. --
