Bug 7492 – [CTFE] Error at assign to immutable character array

--- auto f() { return new char[1]; } immutable s = f(); // error, works with non-character arrays --- Error: cannot implicitly convert expression ("\xff") of type char[] to immutable(char[])

I'm not sure about this. The int[] case may be an accepts-invalid bug. If you move the declaration of 's' into the inside of a function, you get the same error message, even though CTFE is not involved. And when you do that, if it's an int[] instead of char[], you get the same error. In any case the error is not generated by CTFE.

(In reply to Denis Shelomovskij from comment #0) > --- > auto f() { return new char[1]; } > > immutable s = f(); // error, works with non-character arrays > --- > Error: cannot implicitly convert expression ("\xff") of type char[] to > immutable(char[]) The function returns char[]. In D type system, char[] to immutable(char[]) conversion is not allowed. If you annotate the function f with pure attribute, f() will return an unique array so compiler will allow the conversion. Anyway, this is not CTFE problem. The code is trying to violate D type system, and compiler reports the error correctly.

(In reply to Kenji Hara from comment #2) > (In reply to Denis Shelomovskij from comment #0) > > --- > > auto f() { return new char[1]; } > > > > immutable s = f(); // error, works with non-character arrays > > --- > > Error: cannot implicitly convert expression ("\xff") of type char[] to > > immutable(char[]) > > The function returns char[]. In D type system, char[] to immutable(char[]) > conversion is not allowed. > > If you annotate the function f with pure attribute, f() will return an > unique array so compiler will allow the conversion. > > Anyway, this is not CTFE problem. The code is trying to violate D type > system, and compiler reports the error correctly. If function is executed during CTFE it's definitely effectively `pure` for given parameters so I don't understand your arguments. Anyway "works with non-character arrays" comment isn't addressed. Event if this compiler error is an expected behaviour, the issue is in the fact other types don't produce the same error (try e.g. `int` and `Object` arrays).

(In reply to Denis Shelomovskij from comment #3) > If function is executed during CTFE it's definitely effectively `pure` for > given parameters so I don't understand your arguments. Again, CTFE is not relevant. The OP code just fails to pass semantic analysis. CTFE never runs on invalid code. > Anyway "works with non-character arrays" comment isn't addressed. Event if > this compiler error is an expected behaviour, the issue is in the fact other > types don't produce the same error (try e.g. `int` and `Object` arrays). Is that diagnostic issue? Please file another report. Thanks!

(In reply to Kenji Hara from comment #4) > (In reply to Denis Shelomovskij from comment #3) > > Anyway "works with non-character arrays" comment isn't addressed. Event if > > this compiler error is an expected behaviour, the issue is in the fact other > > types don't produce the same error (try e.g. `int` and `Object` arrays). > > Is that diagnostic issue? Please file another report. Thanks! Filed issue 14017.

can't the compiler imply pure on f?

(In reply to Denis Shelomovskij from comment #5) > Filed issue 14017. By looking the code in 14017, I recognized the real issue at last... Full code to illustrate issue. int[] f() { return new int[](1); } char[] g() { return new char[](1); } immutable( int[]) a = f(); // [A] accepted immutable(char[]) s = g(); // [B] rejected If we just only consider type system, both conversions: int[] to immutable( int[]) char[] to immutable(char[]) are not possible. But if we also consider CTFE, we can regard that the function calls will be replaced with the literals that returned by CTFE: immutable( int[]) a = [0]; immutable(char[]) s = ['\xff']; and literals can be convertible to the variable type. --- By looking dmd internals, current semantic process is nearly the latter replacement model. And maybe the [B] case is happened by the issue in the interpreter code for scrubbing CTFE return value. But, at the same time the case [A] looks like a kind of type system breaking. Anyway, at least it's an inconsistent compiler behavior. I reopen this.

(In reply to Kenji Hara from comment #7) > (In reply to Denis Shelomovskij from comment #5) > > Filed issue 14017. > ... > Anyway, at least it's an inconsistent compiler behavior. I reopen this. Issue 14017 is about this inconsistent behavior. Also we both changed our positions. I see no reasonable profit from "effectively `pure`" CTFE-able functions and worst of all such feature will introduce unpleasant inconsistency: --- int[] f() { return new int[1]; } void main() { // With effectively `pure` feature: static immutable s = f(); // OK immutable s = f(); // error } --- So I'm for marking this one as INVALID and for fixing Issue 14017.

(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.

(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.