On Saturday, 30 May 2015 at 08:22:21 UTC, Martin Nowak wrote:
> On Saturday, 30 May 2015 at 00:50:39 UTC, Steven Schveighoffer wrote:
>> I suggest first we build a library AA that sits beside real AA, even if it doesn't . Then we create a test suite to prove that the library AA can be a drop in replacement. Then replace it :)
>
> Writing the AA is NOT the problem, but I doubt we can get compatible enough to replace the built-in AA. Rather it'll require to deprecate a few built-in AA semantics and adding operator and literal extensions for the library type.
> Hence the proposal to start with a HQ library AA and incrementally converge them.

My idea is slihtly of topic.
I thiking about some API for array and associative array literals. Something similar to our range API: front, popFront, etc. It would be good (as I think) if programmer could be able to use Array, or AA literal directly (like maybe initializer list in C++). So for example some class or struct could be initialized from AA literal directly. And another option could be having heterogenous types in Array and AA, so we could use them in a way we work with tuples. So we could use AA literal to initialize JSON objects directly for example using different types of values inside.

auto json = [ "name": "John", "age": 30, "interests": ["programming", "D lang"] ];

Also we could be able to initialize tuple from such heterogenous Array literal. So literals would be not only available for processing by core language and runtime, but also for regular D classes, structs and templates. It could significantly help with initializing complex objects. It would be big change. But what do you thing about just about idea?

On Wednesday, 8 July 2015 at 06:11:25 UTC, Uranuz wrote:
> My idea is slihtly of topic.
> I thiking about some API for array and associative array literals.

There is already an API for array literals, typesafe variadic arguments.

void foo(int[] literal...);
foo([0, 1, 2, 3]);

> But what do you thing about just about idea?

We discussed this already.
https://issues.dlang.org/show_bug.cgi?id=11658
AA and array literals come with literals coercion rules, heterogeneous literals would make the semantics of the literal depend on the callsite.

We already have TypeTuple/Arguments for heterogeneous tuples.

On Wednesday, 8 July 2015 at 08:24:00 UTC, Martin Nowak wrote:
> On Wednesday, 8 July 2015 at 06:11:25 UTC, Uranuz wrote:
>> My idea is slihtly of topic.
>> I thiking about some API for array and associative array literals.
>
> There is already an API for array literals, typesafe variadic arguments.
>
> void foo(int[] literal...);
> foo([0, 1, 2, 3]);
>
>> But what do you thing about just about idea?
>
> We discussed this already.
> https://issues.dlang.org/show_bug.cgi?id=11658
> AA and array literals come with literals coercion rules, heterogeneous literals would make the semantics of the literal depend on the callsite.
>
> We already have TypeTuple/Arguments for heterogeneous tuples.

As far as I understand from that discussion it this feature was not accepted because of template bloat. Am I wrong? But it could be very useful in situations. Another way is to create specific parser that will parse some JSON-like DSL and genetate some code after it that will create specific data structure. But I think it not so nice an will lead to creation of different flavours and parsers for such DSL's.

On 07/08/2015 02:20 PM, Uranuz wrote:
> As far as I understand from that discussion it this feature was not accepted because of template bloat. Am I wrong?

The main reason is that AA literals already have an incompatible semantic.

pragma(msg, typeof(["0": ubyte(0), "1": ushort(1)]));

prints int[string]

Heterogeneous AA literals would require to move that type coercion from
the compiler into the AA constructor.
That's bad b/c the behavior of the literal would depend on the callee.
And it would be difficult to avoid type conversion at runtime and
template bloat for each different literal.

On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
> Would be interesting to get some opinions on this.
>
> https://github.com/D-Programming-Language/druntime/pull/1282

Bringing up this topic again b/c there was still almost no feedback on the actual plan. Here is a summary.

- built-in AA is too magic to be replaced by library AA
- provide a general purpose library AA with enough benefits for people to live with incompatibilities
- add a cheap toBuiltinAA adapter for compatibility of the library AA with existing code
- make array and AA literals usable with UDTs
- slowly deprecated magic behavior of the built-in AA
- switch built-in AA to library AA

Also we should plan for a std.container.aa to deal w/ all the fancy generic/specialized stuff.

On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote:
> On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
>> Would be interesting to get some opinions on this.
>>
>> https://github.com/D-Programming-Language/druntime/pull/1282
>
> Bringing up this topic again b/c there was still almost no feedback on the actual plan. Here is a summary.
>
> - built-in AA is too magic to be replaced by library AA
> - provide a general purpose library AA with enough benefits for people to live with incompatibilities
> - add a cheap toBuiltinAA adapter for compatibility of the library AA with existing code
> - make array and AA literals usable with UDTs
> - slowly deprecated magic behavior of the built-in AA
> - switch built-in AA to library AA
>
> Also we should plan for a std.container.aa to deal w/ all the fancy generic/specialized stuff.

LGTM

Dne 23.9.2016 v 09:39 Martin Nowak via Digitalmars-d napsal(a):

> On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
>> Would be interesting to get some opinions on this.
>>
>> https://github.com/D-Programming-Language/druntime/pull/1282
>
> Bringing up this topic again b/c there was still almost no feedback on the actual plan. Here is a summary.
>
> - built-in AA is too magic to be replaced by library AA
> - provide a general purpose library AA with enough benefits for people to live with incompatibilities
> - add a cheap toBuiltinAA adapter for compatibility of the library AA with existing code
> - make array and AA literals usable with UDTs
> - slowly deprecated magic behavior of the built-in AA
> - switch built-in AA to library AA
>
> Also we should plan for a std.container.aa to deal w/ all the fancy generic/specialized stuff.

What is wrong with built-in AAs? And what advantages comes with library AAs?

On Friday, 23 September 2016 at 07:56:02 UTC, Daniel Kozak wrote:
> What is wrong with built-in AAs? And what advantages comes with library AAs?

http://forum.dlang.org/post/uybkxmjlpswufhiwcawp@forum.dlang.org

On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote:
>
> Bringing up this topic again b/c there was still almost no feedback on the actual plan.

Is there any benefit to adding new operator overloading to handle this case, like a opValueAssign instead of opIndexAssign ?

On Friday, 23 September 2016 at 15:17:26 UTC, jmh530 wrote:
> On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote:
> Is there any benefit to adding new operator overloading to handle this case, like a opValueAssign instead of opIndexAssign ?

Maybe, making the two implementations behave identical can be done from both sides, i.e. we'll definitely make literals work for UDTs at some point, and given how widespread aa[key1][key2]++ is used we might want to come up with a UDT solution as well, but we can discuss this as a detail when we're at it.

One nice property of the plan is that it's already broken down into digestible changes, might get stuck or fail at any point, but still provides value from the first step on.