Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 2012-03-15 23:59, foobar wrote: On Thursday, 15 March 2012 at 10:39:04 UTC, Steven Schveighoffer wrote: Why would that pose a problem to DMD? object.d is a regular D module and D provides a public import feature. If that fails for some modules it should be considered a bug in the compiler. I disagree about the side of the benefit. This gains us readability of code which is IMO a MAJOR benefit. It's not just the object.d module but a lot of phobos too. It frustrates me to no end Andrei's refusal to accept a design proven to work for half a century (which is already utilized by the compiler!) - the File System. Choosing instead to duplicate organization features inside DDOC as sections. This is a classic example of a code smell. I completely agree. -- /Jacob Carlborg
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Wednesday, 14 March 2012 at 23:14:42 UTC, H. S. Teoh wrote: Alright, I've finished the basic functionality of my AA implementation. I still haven't solved that problem with using suffixless string literals to index X[dstring], so you'll have to write aa[abcd] instead of just aa[abc]. But I thought I should post my code now so that people can take a look at it: https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d T Thanks for tackling the AA problem. I have one slight issue / comment regarding AAs: I really dislike the idea of cramming everything under the sun into object.d. In general, cramming lots'o'code into a single mega file is a code smell which Phobos greatly stinks from. At the very least, object.d can publicly import your newAA.d module which gives the exact same outcome while keeping separate features separate.
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 2012-03-15 08:59, foobar wrote: On Wednesday, 14 March 2012 at 23:14:42 UTC, H. S. Teoh wrote: Alright, I've finished the basic functionality of my AA implementation. I still haven't solved that problem with using suffixless string literals to index X[dstring], so you'll have to write aa[abcd] instead of just aa[abc]. But I thought I should post my code now so that people can take a look at it: https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d T Thanks for tackling the AA problem. I have one slight issue / comment regarding AAs: I really dislike the idea of cramming everything under the sun into object.d. In general, cramming lots'o'code into a single mega file is a code smell which Phobos greatly stinks from. At the very least, object.d can publicly import your newAA.d module which gives the exact same outcome while keeping separate features separate. I think object.d should be empty except for the definition of Object. The rest should be located in their own modules and publicly imported in object.d -- /Jacob Carlborg
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, 15 Mar 2012 06:19:33 -0400, Jacob Carlborg d...@me.com wrote: On 2012-03-15 08:59, foobar wrote: On Wednesday, 14 March 2012 at 23:14:42 UTC, H. S. Teoh wrote: Alright, I've finished the basic functionality of my AA implementation. I still haven't solved that problem with using suffixless string literals to index X[dstring], so you'll have to write aa[abcd] instead of just aa[abc]. But I thought I should post my code now so that people can take a look at it: https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d T Thanks for tackling the AA problem. I have one slight issue / comment regarding AAs: I really dislike the idea of cramming everything under the sun into object.d. In general, cramming lots'o'code into a single mega file is a code smell which Phobos greatly stinks from. At the very least, object.d can publicly import your newAA.d module which gives the exact same outcome while keeping separate features separate. I think object.d should be empty except for the definition of Object. The rest should be located in their own modules and publicly imported in object.d I think the compiler would have to change for that to happen. I would support such a change, but then again, it seems like we'd get little measurable benefit for it, making it difficult to get through Walter. -Steve
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 2012-03-15 11:39, Steven Schveighoffer wrote: On Thu, 15 Mar 2012 06:19:33 -0400, Jacob Carlborg d...@me.com wrote: I think object.d should be empty except for the definition of Object. The rest should be located in their own modules and publicly imported in object.d I think the compiler would have to change for that to happen. I would support such a change, but then again, it seems like we'd get little measurable benefit for it, making it difficult to get through Walter. -Steve Why would the compiler need to be changed for that? -- /Jacob Carlborg
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, 15 Mar 2012 06:47:00 -0400, Jacob Carlborg d...@me.com wrote: On 2012-03-15 11:39, Steven Schveighoffer wrote: On Thu, 15 Mar 2012 06:19:33 -0400, Jacob Carlborg d...@me.com wrote: I think object.d should be empty except for the definition of Object. The rest should be located in their own modules and publicly imported in object.d I think the compiler would have to change for that to happen. I would support such a change, but then again, it seems like we'd get little measurable benefit for it, making it difficult to get through Walter. -Steve Why would the compiler need to be changed for that? Isn't full name of TypeInfo object.TypeInfo? Is that not hard-coded into the compiler? -Steve
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 2012-03-15 11:52, Steven Schveighoffer wrote: Isn't full name of TypeInfo object.TypeInfo? Is that not hard-coded into the compiler? -Steve I have no idea if object.TypeInfo is hard-coded into the compiler. -- /Jacob Carlborg
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 15/03/12 00:16, H. S. Teoh wrote: On Tue, Mar 13, 2012 at 09:30:45PM -0500, Andrei Alexandrescu wrote: On 3/13/12 7:54 PM, H. S. Teoh wrote: Hi all, My AA implementation is slowly inching closer to being ready to replace aaA.d. Great! This will need compiler restructuring, and in fact offers the perfect opportunity for it. I suggest you to post your implementation here for review first, and assume only the minimal lowerings from the compiler. Alright, I've finished the basic functionality of my AA implementation. I still haven't solved that problem with using suffixless string literals to index X[dstring], so you'll have to write aa[abcd] instead of just aa[abc]. But I thought I should post my code now so that people can take a look at it: https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d Currently, this code is still standalone, not integrated with druntime yet. Since that will require compiler changes and is potentially a very big change, I've decided to polish up the standalone version as much as possible before attempting druntime integration. 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?
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
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? Andrei
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, 15 Mar 2012 12:05:46 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org 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? 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. -Steve
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, Mar 15, 2012 at 05:02:06PM +0100, Don Clugston wrote: On 15/03/12 00:16, H. S. Teoh 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. How does the compiler currently work with AA literals? I see two functions in aaA.d for constructing AA's from literals. Which one is the one actually being used? One possibility might be to accept a pair of array literals, representing keys and values. OK. This shouldn't be hard to do. I'll take a stab at it. Possibly it should call a CTFE function to convert them into some other form? This is one major area that I forgot to mention, and that is, making AA literals work at compile-time. Currently things like this don't work: enum myAA = [abc:123, def:456]; I'd like to make that work. That would require compile-time construction of the AA and storing it in some form that the compiler can put into the object file. I'm thinking of something along the lines of using mixins to generate explicit instances of Slot structs, so the above would translate to something like: Impl __myAA_literal_impl = Impl(__myAA_literal_slots[0..$], 2); Slot[4] __myAA_literal_slots = [ // The exact order in here will depend on precise hash // values, which will need to be somehow computed by // CTFE. Is that even remotely possible right now?? null, __myAA_literal_slot1, null, __myAA_literal_slot2 ]; Slot __myAA_literal_slot1 = Slot(null, /*hash value*/, abc, 123); Slot __myAA_literal_slot2 = Slot(null, /*hash value*/, def, 456); enum myAA = AssociativeArray!(string,int)(__myAA_literal_impl); Would something like this be workable? Is it even possible to compute the necessary hashes at compile-time? T -- Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 3/15/12 12:12 PM, Steven Schveighoffer wrote: On Thu, 15 Mar 2012 12:05:46 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org 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. 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? Andrei
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, 15 Mar 2012 13:24:24 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 3/15/12 12:12 PM, Steven Schveighoffer wrote: On Thu, 15 Mar 2012 12:05:46 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org 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
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, 15 Mar 2012 13:39:19 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Thu, 15 Mar 2012 13:24:24 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: 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. Sorry, that should really be: auto aa = AssociativeArray!(int, int)(__k[], __v[]); -Steve
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 3/15/12 12:39 PM, Steven Schveighoffer wrote:
On Thu, 15 Mar 2012 13:24:24 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
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.
I guess I should ask this then: why is instantiating a template function
a problem?
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.
That should work, too. Use braces to not require a fix:
int[1] __k = {1};
int[1] __v = {1};
auto aa = AssociativeArray!(int, int)(__k, __v);
Off the top of my head it changes the order of evaluation in the general
case (or complicates code generation if left-to-right preservation is
needed). Also the constructor needs to be @trusted because references to
static arrays can't escape in safe code. All workable matters, but
generally I prefer migrating cleverness from code generation into
library code.
Andrei
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, Mar 15, 2012 at 10:22:06AM -0700, H. S. Teoh wrote: [...] This is one major area that I forgot to mention, and that is, making AA literals work at compile-time. Currently things like this don't work: enum myAA = [abc:123, def:456]; I'd like to make that work. That would require compile-time construction of the AA and storing it in some form that the compiler can put into the object file. I'm thinking of something along the lines of using mixins to generate explicit instances of Slot structs, so the above would translate to something like: [...] Hmm. I just did a little test to see how feasible this is, and I create the AA Slots and array of pointers to slots fine, but hashOf() doesn't work in CTFE: /usr/src/d/druntime/src/rt/util/hash.d(38): Error: reinterpreting cast from const(ubyte)* to ushort* is not supported in CTFE /usr/src/d/druntime/src/rt/util/hash.d(72):called from here: get16bits(data) Should I submit a pull request for a __ctfe variant of hashOf so that it can be used for this purpose? Any gotchas I should be aware of? T -- I'm running Windows '98. Yes. My computer isn't working now. Yes, you already said that. -- User-Friendly
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, 15 Mar 2012 14:11:11 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 3/15/12 12:39 PM, Steven Schveighoffer wrote: On Thu, 15 Mar 2012 13:24:24 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: 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. I guess I should ask this then: why is instantiating a template function a problem? 1. non-inlined functions (dmd doesn't inline by default) result in extra calls. 2. I think even if it's inlined, dmd generates a function and sticks it in the object file, which will never be called. (bloat). I'm not sure if anything else is put into the binary, or if the function is optimized out on linking. Off the top of my head it changes the order of evaluation in the general case (or complicates code generation if left-to-right preservation is needed). Also the constructor needs to be @trusted because references to static arrays can't escape in safe code. All workable matters, but generally I prefer migrating cleverness from code generation into library code. All good points. One thing to be sure, given the fact that this is one hook implemented in one location, it should be easy to fix later if we use a bad approach. Perhaps the best way to address my concerns are to fix how unused templates are included in the binary. I could also be wrong about that. -Steve
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 15.03.2012 21:22, H. S. Teoh wrote: On Thu, Mar 15, 2012 at 05:02:06PM +0100, Don Clugston wrote: On 15/03/12 00:16, H. S. Teoh 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. How does the compiler currently work with AA literals? I see two functions in aaA.d for constructing AA's from literals. Which one is the one actually being used? One possibility might be to accept a pair of array literals, representing keys and values. OK. This shouldn't be hard to do. I'll take a stab at it. Possibly it should call a CTFE function to convert them into some other form? This is one major area that I forgot to mention, and that is, making AA literals work at compile-time. Currently things like this don't work: enum myAA = [abc:123, def:456]; I'd like to make that work. That would require compile-time construction of the AA and storing it in some form that the compiler can put into the object file. What's wrong with AA structure itself, it's link-pointer based? At any rate, I stored complex structs as immutable, though links were index-based. I'm thinking of something along the lines of using mixins to generate explicit instances of Slot structs, so the above would translate to something like: Impl __myAA_literal_impl = Impl(__myAA_literal_slots[0..$], 2); Slot[4] __myAA_literal_slots = [ // The exact order in here will depend on precise hash // values, which will need to be somehow computed by // CTFE. Is that even remotely possible right now?? null, __myAA_literal_slot1, null, __myAA_literal_slot2 ]; Slot __myAA_literal_slot1 = Slot(null, /*hash value*/, abc, 123); Slot __myAA_literal_slot2 = Slot(null, /*hash value*/, def, 456); enum myAA = AssociativeArray!(string,int)(__myAA_literal_impl); Would something like this be workable? Is it even possible to compute the necessary hashes at compile-time? T -- Dmitry Olshansky
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thursday, 15 March 2012 at 10:39:04 UTC, Steven Schveighoffer wrote: On Thu, 15 Mar 2012 06:19:33 -0400, Jacob Carlborg I think object.d should be empty except for the definition of Object. The rest should be located in their own modules and publicly imported in object.d I think the compiler would have to change for that to happen. I would support such a change, but then again, it seems like we'd get little measurable benefit for it, making it difficult to get through Walter. -Steve Why would that pose a problem to DMD? object.d is a regular D module and D provides a public import feature. If that fails for some modules it should be considered a bug in the compiler. I disagree about the side of the benefit. This gains us readability of code which is IMO a MAJOR benefit. It's not just the object.d module but a lot of phobos too. It frustrates me to no end Andrei's refusal to accept a design proven to work for half a century (which is already utilized by the compiler!) - the File System. Choosing instead to duplicate organization features inside DDOC as sections. This is a classic example of a code smell.
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, Mar 15, 2012 at 11:50:47PM +0400, Dmitry Olshansky wrote: [...] This is one major area that I forgot to mention, and that is, making AA literals work at compile-time. Currently things like this don't work: enum myAA = [abc:123, def:456]; I'd like to make that work. That would require compile-time construction of the AA and storing it in some form that the compiler can put into the object file. What's wrong with AA structure itself, it's link-pointer based? At any rate, I stored complex structs as immutable, though links were index-based. Yes, that's what I had in mind. In fact, I've starting testing a statically-declared AA (written by hand for now), that uses the same structures as heap-allocated AA's. The basic stuff (declaring Slots statically, linking them together, etc.) works, and in principle can be generated by mixins at compile-time to give us true compile-time AA literals (as in, the AA struct is computed at compile-time and stored in the static data segment in the object file). This can be used for implementing immutable AA's at compile-time (and maybe also fast initialization of AA literals which can be .dup'd at runtime into mutable AA's when needed). However, I've run into a major roadblock: the hash computation of the keys itself. Unfortunately, currently there's no (reliable) way to compute the hash of built-in types unless you use its TypeInfo, and TypeInfo's are currently not CTFE-accessible, so hash values cannot be computed at compile-time. :-( T -- He who laughs last thinks slowest.
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 3/15/12 5:59 PM, foobar wrote: It frustrates me to no end Andrei's refusal to accept a design proven to work for half a century (which is already utilized by the compiler!) - the File System. Choosing instead to duplicate organization features inside DDOC as sections. This is a classic example of a code smell. What, what? What did I do? Andrei
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thursday, March 15, 2012 21:10:43 Andrei Alexandrescu wrote: On 3/15/12 5:59 PM, foobar wrote: It frustrates me to no end Andrei's refusal to accept a design proven to work for half a century (which is already utilized by the compiler!) - the File System. Choosing instead to duplicate organization features inside DDOC as sections. This is a classic example of a code smell. What, what? What did I do? Yeah. That comment makes no sense. More context is needed. - Jonathan M Davis
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Thu, Mar 15, 2012 at 05:02:06PM +0100, 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. Alright, I've made a preliminary implementation of AA literals as a function that constructs an AA given an array of keys and and an array of values (just like the current aaA.d implementation). The changes have been pushed to github: https://github.com/quickfur/New-AA-implementation/commit/c272909626f09829f33346746250c2a1e8d2 Currently this function is a static member; I'm thinking maybe it might be better to make it an external template function instead. That way, we only need the compiler to do array type inference for the input arrays, and the function will use the inferred types to determine the AA key/value types. Possibly it should call a CTFE function to convert them into some other form? I do intend to do more with AA literals, including making them compileable into object code directly (using static struct instances and mixins), but that will be more involved, and will require implementing toHash() for all native types using UFCS, that I proposed in another thread. A quick hand-crafted test earlier today showed that it *can* be done; it's just a matter of getting the various pieces in place. T -- Curiosity kills the cat. Moral: don't be the cat.
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On 3/14/12 6:16 PM, H. S. Teoh wrote: - Declaring an AA with non-const array keys will cause reams and reams of compile errors. I'm not *too* worried about this at the moment since it doesn't make sense to have non-const AA keys anyway. I'm also seriously considering forcing *all* AA keys to be immutable, in which case this will become a non-issue. I think the built-in associative array must allow non-constant keys. As long as there's no memory safety issue, the AA should work with types that the user doesn't change for comparison purposes but can otherwise modify. A practical matter is that if we introduce this restriction we'll break a ton of code. Andrei
Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)
On Wed, Mar 14, 2012 at 11:58:01PM -0500, Andrei Alexandrescu wrote: On 3/14/12 6:16 PM, H. S. Teoh wrote: - Declaring an AA with non-const array keys will cause reams and reams of compile errors. I'm not *too* worried about this at the moment since it doesn't make sense to have non-const AA keys anyway. I'm also seriously considering forcing *all* AA keys to be immutable, in which case this will become a non-issue. I think the built-in associative array must allow non-constant keys. As long as there's no memory safety issue, the AA should work with types that the user doesn't change for comparison purposes but can otherwise modify. A practical matter is that if we introduce this restriction we'll break a ton of code. [...] Understood. But if the user changes the keys then the AA will malfunction. (This is no worse than the current behaviour, I suppose.) So now I've to track down why non-const keys trigger a ton of errors... :-/ T -- No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex. -- Simon St. Laurent on xml-dev
