On Thu, 15 Mar 2012 13:24:24 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 3/15/12 12:12 PM, Steven Schveighoffer wrote:
On Thu, 15 Mar 2012 12:05:46 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 3/15/12 11:02 AM, Don Clugston wrote:
This is good, and very, very important. Do *not* make any attempt at
compiler integration until it is *completely* ready.
This includes AA literals. They need to be accepted somehow. The
compiler will give you syntax sugar and *nothing* more.
One possibility might be to accept a pair of array literals,
representing keys and values.
Possibly it should call a CTFE function to convert them into some
other
form?
Offhand, I think this rewrite should be sufficient:
[e11:e12, e21:e22]
--->
.object.associativeArrayLiteral(e11, e12, e21, e22)
Then type manipulation and template constraints can take care of the
rest. Am I missing something?
Wouldn't this require a new template instantiation for each sized AA per
key/value type? Or were you planning to use varargs?
Template function takes over, does whatever is necessary, such as
possibly conversion to varargs.
Right, but with a template:
[1:1]
[1:1, 2:2]
become two separate template instantiations, but with something that just
takes two arrays, it's only one template, no matter how many elements you
are initializing with.
So long as the data that is actually passed to the AA is on the stack
(and simply a slice is passed), I like Don's idea better.
What would that look like?
auto aa = [1:1];
becomes:
int[1] __k = [1]; // obviously, no heap allocation should happen here,
that needs fixing in the compiler
int[1] __v = [1];
auto aa = AssociativeArray!(int, int)(__k, __v); // same instantiation, no
matter how many elements are in literal.
-Steve
