On 2016-01-05 15:44, Minas Mina wrote:

> It won't, but to use it again you need to allocate a new one (If I'm not
> mistaken).

Not explicitly. I don't know if the runtime allocates a new one. This works:

void main()
{
    auto foo = ["foo" : 1];
    foo = null;
    foo["bar"] = 2;
    assert(foo["bar"] == 2);
}

-- 
/Jacob Carlborg

On Wednesday, 6 January 2016 at 12:19:45 UTC, Jacob Carlborg wrote:
> On 2016-01-05 15:44, Minas Mina wrote:
>
>> It won't, but to use it again you need to allocate a new one (If I'm not
>> mistaken).
>
> Not explicitly. I don't know if the runtime allocates a new one. This works:
>
> void main()
> {
>     auto foo = ["foo" : 1];
>     foo = null;
>     foo["bar"] = 2;
>     assert(foo["bar"] == 2);
> }

I believe it does, check out this example:
import std.stdio;

class C
{
    int[int] squares;
}

void main()
{
    auto squares = [0 : 0, 1 : 1];

    C c = new C();
    c.squares = squares;

    writeln(c.squares is squares); // true

    squares = null;
    squares[10] = 100;
    writeln(c.squares is squares); // false
}

If the runtime used the same underlying memory, the second writeln() would print true, right?
So if I am correct, a new AA is allocated.

On 06 Jan 2016 3:25 PM, "Minas Mina via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 6 January 2016 at 12:19:45 UTC, Jacob Carlborg wrote:
>>
>> On 2016-01-05 15:44, Minas Mina wrote:
>>
>>> It won't, but to use it again you need to allocate a new one (If I'm not
>>> mistaken).
>>
>>
>> Not explicitly. I don't know if the runtime allocates a new one. This
works:
>>
>> void main()
>> {
>>     auto foo = ["foo" : 1];
>>     foo = null;
>>     foo["bar"] = 2;
>>     assert(foo["bar"] == 2);
>> }
>
>
> I believe it does, check out this example:
> import std.stdio;
>
> class C
> {
>     int[int] squares;
> }
>
> void main()
> {
>     auto squares = [0 : 0, 1 : 1];
>
>     C c = new C();
>     c.squares = squares;
>
>     writeln(c.squares is squares); // true
>
>     squares = null;
>     squares[10] = 100;
>     writeln(c.squares is squares); // false
> }
>
> If the runtime used the same underlying memory, the second writeln()
would print true, right?
> So if I am correct, a new AA is allocated.
Probably depends on the current implementation. If you are using an associative array you are going to be allocating at least a little.

If you used an associative array backed by two arrays you could allocate and reuse memory when null is assigned. It would also be able to keep its insertion order.

On Sunday, 3 January 2016 at 19:29:05 UTC, Martin Nowak wrote:
> There is a bug.
>
> You should never do this b/c of iterator/range invalidation.
>
> foreach (key; aa.keys)
>     aa.remove(key);

I've recently hit this when trying to remove some of the elements from an AA while iterating over it. It's easy to forget that it is not allowed, especially when working on more complex algorithms. Accidentally, it worked all fine even with large data sets with DMD 2.069, but with GDC mysterious segfaults appeared - the first thought in such case was obviously a bug in GDC or in the older front-end.

However, this is a very convenient, natural and intuitive syntax for something that is needed quite frequently, yet this code breaks silently in non-predictable ways.
There are already registered issues concerning this (or similar with insertion) problem, including:

https://issues.dlang.org/show_bug.cgi?id=4179
https://issues.dlang.org/show_bug.cgi?id=2255
https://issues.dlang.org/show_bug.cgi?id=10821
https://issues.dlang.org/show_bug.cgi?id=10876
https://issues.dlang.org/show_bug.cgi?id=13903

I've personally encountered segfaults, infinite loops, programs producing incorrect results. Some solutions to this were proposed in the bug reports - either:
a) explicitly allow removing during iteration, and make sure it always works, or
b) explicitly disallow removing during iteration, and always throw an Error whenever it is attempted. In some cases it could even be detectable in compile time.

And I don't mean including a single sentence about this somewhere in the docs. I mean an error reported by the compiler and/or runtime. The runtime checks could be disabled for -release, but there should be at least an option to detect such errors.
Probably the worst part of it is that you're free to wrap it in @safe, while it's not safe at all.

On Thursday, 7 January 2016 at 12:26:29 UTC, Adrian Matoga wrote:
> b) explicitly disallow removing during iteration, and always throw an Error whenever it is attempted. In some cases it could even be detectable in compile time.
>
> And I don't mean including a single sentence about this somewhere in the docs. I mean an error reported by the compiler and/or runtime. The runtime checks could be disabled for -release, but there should be at least an option to detect such errors.

We don't have the means to do that currently, neither at compile-time, nor at runtime. Both would require some kind of borrowing detection, either to make the AA `const` during iteration, or to set and reset a flag indicating that it's being iterated, allowing it to assert() at runtime.

> Probably the worst part of it is that you're free to wrap it in @safe, while it's not safe at all.

That's something we can change right now. I guess `remove` must be `@system`.

On 1/7/16 7:26 AM, Adrian Matoga wrote:
> On Sunday, 3 January 2016 at 19:29:05 UTC, Martin Nowak wrote:
>> There is a bug.
>>
>> You should never do this b/c of iterator/range invalidation.
>>
>> foreach (key; aa.keys)
>>     aa.remove(key);
>
> I've recently hit this when trying to remove some of the elements from
> an AA while iterating over it. It's easy to forget that it is not
> allowed, especially when working on more complex algorithms.
> Accidentally, it worked all fine even with large data sets with DMD
> 2.069, but with GDC mysterious segfaults appeared - the first thought in
> such case was obviously a bug in GDC or in the older front-end.
>
> However, this is a very convenient, natural and intuitive syntax for
> something that is needed quite frequently, yet this code breaks silently
> in non-predictable ways.
> There are already registered issues concerning this (or similar with
> insertion) problem, including:
>
> https://issues.dlang.org/show_bug.cgi?id=4179
> https://issues.dlang.org/show_bug.cgi?id=2255
> https://issues.dlang.org/show_bug.cgi?id=10821
> https://issues.dlang.org/show_bug.cgi?id=10876
> https://issues.dlang.org/show_bug.cgi?id=13903
>
> I've personally encountered segfaults, infinite loops, programs
> producing incorrect results. Some solutions to this were proposed in the
> bug reports - either:
> a) explicitly allow removing during iteration, and make sure it always
> works, or
> b) explicitly disallow removing during iteration, and always throw an
> Error whenever it is attempted. In some cases it could even be
> detectable in compile time.
>
> And I don't mean including a single sentence about this somewhere in the
> docs. I mean an error reported by the compiler and/or runtime. The
> runtime checks could be disabled for -release, but there should be at
> least an option to detect such errors.
> Probably the worst part of it is that you're free to wrap it in @safe,
> while it's not safe at all.
>

With dcollections [1] I had a feature called "purging" where you would iterate over a collection like this:

foreach(ref bool removeIt, int val; collection)
{
   if(someCondition) removeIt = true;
}

The entire reason for this is because you can do something similar in C++ containers, and I found it absolutely annoying that the existing container classes don't allow this. A very frequent use of containers is to iterate through picking which ones should be removed (think of a cache)

-Steve

[1] http://schveiguy.github.io/dcollections/

On 2016-01-07 15:11, Steven Schveighoffer wrote:

> With dcollections [1] I had a feature called "purging" where you would
> iterate over a collection like this:
>
> foreach(ref bool removeIt, int val; collection)
> {
>     if(someCondition) removeIt = true;
> }
>
> The entire reason for this is because you can do something similar in
> C++ containers, and I found it absolutely annoying that the existing
> container classes don't allow this. A very frequent use of containers is
> to iterate through picking which ones should be removed (think of a cache)

In Ruby that's called "reject", i.e. the opposite of "filter".

-- 
/Jacob Carlborg

WBvDda> http://minas-mina.com/2016/01/01/associative-arrays/

This article translated into Russian: http://habrahabr.ru/post/274723/


-- 
With best regards from Ukraine,
Andre
Skype: Francophile
Twitter: @m_elensule; Facebook: menelion