Would be interesting to get some opinions on this.

https://github.com/D-Programming-Language/druntime/pull/1282

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

Looks like a good step in the right direction.

Some questions about:

> This provides a strong incentive to no longer use the magic semantics of the builtin AAs,

Could you elaborate on what these magic semantics are?

> and no easy solution exists for the ++aa[key1][key2] case.

Is this specific to the pre-increment? aa[key1][key2]++ is generally a useful pattern.

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

BTW, I have one idea. We may declare the AA ABI:
AA is a pointer to the next layout:

__vtbl
N bytes of data

and __vtbl is a pointer to a struct:
struct AAVTBL
{
    size_t function() size; //returns the size of AA object: N + (AABTBL*).sizeof
    void* get(void* aa, @somefields@)
    //another function
}

And it we teach compiler to use this ABI, we may say that any type which follows this ABI is a correct associative array.
At the first stage, we may adapt the existing AA implementation to follow this ABI, and adapt the compiler to use it.
After that, we will adble to write library AA (which also follows this ABI), which may be constructed as general D type, and casted to AA later.

On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev 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
>
> Looks like a good step in the right direction.
>
> Some questions about:
>
>> This provides a strong incentive to no longer use the magic semantics of the builtin AAs,
>
> Could you elaborate on what these magic semantics are?
>
>> and no easy solution exists for the ++aa[key1][key2] case.
>
> Is this specific to the pre-increment? aa[key1][key2]++ is generally a useful pattern.

The general idea that library aa has a vtbl, and standart AA fuctions like _aaGetX will access to our AA via vtbl.
Compiler will operate with aa via all those _aaGetX, _aaLen et c.
Thus aa[x][y]++; will work as early.

On Monday, 25 May 2015 at 23:39:18 UTC, IgorStepanov 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
>
> BTW, I have one idea. We may declare the AA ABI:
> AA is a pointer to the next layout:

This is intended as temporary solution to simplify the transition to a library aa.
Extending this conversion to other types for against the goal to replace the built-in AA.

On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev wrote:
> Could you elaborate on what these magic semantics are?
>
>> and no easy solution exists for the ++aa[key1][key2] case.
>
> Is this specific to the pre-increment? aa[key1][key2]++ is generally a useful pattern.

This applies to pre/post increment as well as assignment and opOpAssign.
When an lvalue is needed the compiler will call a special runtime function GetX to obtain an lvalue for aa[key1], i.e. the entry will be default initialized iff missing.
If the expression is an rvalue though (aa[key1][key2]), a missing key1 will trigger a range error.
In an opIndex(Key) you have no idea whether the whole expression I an lvalue or an rvalue.

IIRC the construction/assignment of a value is also handled specifically.

On Wednesday, 27 May 2015 at 14:12:02 UTC, Martin Nowak wrote:
> On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev wrote:
>> Could you elaborate on what these magic semantics are?
>>
>>> and no easy solution exists for the ++aa[key1][key2] case.
>>
>> Is this specific to the pre-increment? aa[key1][key2]++ is generally a useful pattern.
>
> This applies to pre/post increment as well as assignment and opOpAssign.
> When an lvalue is needed the compiler will call a special runtime function GetX to obtain an lvalue for aa[key1], i.e. the entry will be default initialized iff missing.
> If the expression is an rvalue though (aa[key1][key2]), a missing key1 will trigger a range error.
> In an opIndex(Key) you have no idea whether the whole expression I an lvalue or an rvalue.
>
> IIRC the construction/assignment of a value is also handled specifically.

BTW, may be we should create DIP about opIndex extending?
What do you want about following?
Let, if opIndex is template, and the first template argument is a bool value, compiler should pass true, if this is a part of l-value expression:

struct Foo
{
    Foo[] children;
    this(int value)
    {
        this.value = value;
    }
    int value;

    ref Foo opIndex(bool lvl)(size_t idx)
    {
        if (idx < children.length)
            return children[idx];
        static if (lvl)
        {
            children.length = idx + 1;
            return children[idx];
        }
        else
        {
            throw new Exception("out of bounds");
        }
    }
}


Foo f;
f[5][3] = Foo(42); translates to
    f.opIndex!(true)(5).opIndex!(true)(3) = Foo(42);

auto x = f[5][4]; translates to
    auto x = f.opIndex!(false)(5).opIndex!(false)(3);

On Wed, May 27, 2015 at 05:16:51PM +0000, IgorStepanov via Digitalmars-d wrote:
> On Wednesday, 27 May 2015 at 14:12:02 UTC, Martin Nowak wrote:
> >On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev wrote:
> >>Could you elaborate on what these magic semantics are?
> >>
> >>>and no easy solution exists for the ++aa[key1][key2] case.
> >>
> >>Is this specific to the pre-increment? aa[key1][key2]++ is generally a useful pattern.
> >
> >This applies to pre/post increment as well as assignment and
> >opOpAssign.  When an lvalue is needed the compiler will call a
> >special runtime function GetX to obtain an lvalue for aa[key1], i.e.
> >the entry will be default initialized iff missing.
> >If the expression is an rvalue though (aa[key1][key2]), a missing
> >key1 will trigger a range error.
> >In an opIndex(Key) you have no idea whether the whole expression I an
> >lvalue or an rvalue.
> >
> >IIRC the construction/assignment of a value is also handled specifically.
> 
> BTW, may be we should create DIP about opIndex extending?
[...]

See: https://issues.dlang.org/show_bug.cgi?id=7753

This issue has been known since 2012.


T

-- 
Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard

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

For my own reasons, a library AA is most welcome:
* separating library features from language features
* making features optional and opt-in instead of opt-out
* modularizing the language and runtime for pay-as-you-go implementations

But, if you'll forgive my ignorance, what is the primary motivation for migrating to a library AA?

Mike

On Wednesday, 27 May 2015 at 17:16:53 UTC, IgorStepanov wrote:
> Foo f;
> f[5][3] = Foo(42); translates to
>     f.opIndex!(true)(5).opIndex!(true)(3) = Foo(42);
>
> auto x = f[5][4]; translates to
>     auto x = f.opIndex!(false)(5).opIndex!(false)(3);

We shouldn't replace opIndexAssign though, b/c default construction + assignment is more expensive than constructing in-place.