Associative array literal is non-constant?

[Artur Skawina]

On 02/06/12 21:22, H. S. Teoh wrote:
> On Mon, Feb 06, 2012 at 11:46:00AM -0800, H. S. Teoh wrote:
> [...]
>> As for what type the literal should be by default:
>>
>> 	auto X = ["a":1, "b":2, ...];
>>
>> I think typeof(X) should be const int[string].
> 
> Hmm, I just checked TDPL again, and it seems that precedence has already
> been set for typeof(X) to be non-const.
> 
> Which is OK, I guess, since with the current implementation we have:
> 
> 	auto A = [1,2,3];	// int[]
> 	const B = [1,2,3];	// const(const(int)[]) -- why does
> 				// writeln(typeid(B)) give this funny
> 				// expression?
> 
> 	auto X = ["a":1, "b":2];	// int[immutable(char)[]]
> 	const Y = ["a":1, "b":2];	// const(const(int)[immutable(char)[]])
> 
> (Of course, Y is currently still constructed on the heap.)
> 
> Alternatively, if we don't want to risk breaking backward compatibility,
> maybe the new AA type should be "static T[U]" instead? I.e., introduce a
> new type called "static AA" which has a different implementation that is
> be computed at compile-time, and which is not compatible with the
> current AA's except via a .dup method that creates a heap-based AA.
> 
> (Or should it be "immutable AA"?)

"static AA" is still mutable. "immutable" or "const" are not (you cannot
modify an AA declared as const w/o casting away the constness).

artur