Bug 5074 – array(immutable(int)[]) ==> int[]

This is more an enhancement request than a bug report. In my opinion an array() applied on an array has to act like "dup", just like array(static_array) returns a dynamic array. So I think array(immutable(int)[]) has to return an int[]. With DMD 2.049 array(immutable(int)[]) doesn't work: import std.array: array; void main() { int[4] a0 = [2, 3, 1, 4]; static assert(is(typeof(array(a0)) == int[])); // OK immutable(int)[] a1 = [2, 3, 1, 4]; int[] a2 = a1.dup; int[] a3 = array(a1); // ERROR } Errors generated: ...\dmd\src\phobos\std\array.d(64): Error: result[i] isn't mutable ...\dmd\src\phobos\std\array.d(7): Error: template instance std.array.array!(immutable(int)[]) error instantiating test.d(7): Error: cannot implicitly convert expression (array(a1)) of type immutable(int)[] to int[]

to!(int[])(a) should take care of that.

(In reply to comment #1) > to!(int[])(a) should take care of that. There are also const casts: array(cast(int[])a1) But the design point of array() is to digest anything you may iterate, and produce a dynamic array. So I think array(immutable(int)[]) should not require casts or to!().

I agree with bearophile here; array() should digest whatever you iterate and produce a dynamic array.

(In reply to comment #2) > (In reply to comment #1) > > to!(int[])(a) should take care of that. > > There are also const casts: > > array(cast(int[])a1) > > But the design point of array() is to digest anything you may iterate, and > produce a dynamic array. So I think array(immutable(int)[]) should not require > casts or to!(). In this case, "is(immutable(int) : int)" is true, but this is not true of all types, so array won't be able to do this for any and all types. That said, it doesn't seem ridiculous to me either: 1) Create an array of whatever an IFTI on the element type would produce. 2) Simply make mutable elements for types that can safely be converted to their Unqual type. However, this would be a change of behavior, which may or may not be an improvement, and may or may not break code.

(In reply to comment #4) > However, this would be a change of behavior, which may or may not be an > improvement, and may or may not break code. It will break code. immutable(int)[] a = ...; immutable(int)[] b = array(a); This breaks if array returns int[]. I propose this is closed. array is one of the most commonly used functions in Phobos; I really can't see an API change for it ever happening -- especially one that is of debatable value.

agreed

(In reply to comment #5) > (In reply to comment #4) > > However, this would be a change of behavior, which may or may not be an > > improvement, and may or may not break code. > > It will break code. > > immutable(int)[] a = ...; > immutable(int)[] b = array(a); > > This breaks if array returns int[]. > It doesn't have to! If array is pure, takes some form of const(int)[], and returns int[] then the result will implicitly convert to immutable!

(In reply to comment #7) > It doesn't have to! If array is pure, takes some form of const(int)[], and > returns int[] then the result will implicitly convert to immutable! I had thought of that, but it could still break in subtle ways in regards to inference. Instead of being immutable by default, you have to trigger the conversion. EG. break: //--- immutable a = "hello; auto b = array(a); //is now an dchar[], not dstring :§ ... dstring c = b; //error! //---- I *do* think it's very nice design though, and it *really* shows the strength of pure functions. And there remember there being requests for things like "specify the constness of array", so this change would also fix that. But it would still be a breaking change. A good change (IMO), but still a breaking one.

(In reply to comment #7) > It doesn't have to! If array is pure, takes some form of const(int)[], and > returns int[] then the result will implicitly convert to immutable! See Issue 12282

We don't want `array` to be used to transform qualifiers on existing arrays. For arrays, the function should be identity.