On Thursday, 7 August 2014 at 17:42:29 UTC, Marc Schütz wrote:
On Thursday, 7 August 2014 at 17:35:46 UTC, Puming wrote:
So I'd like to suggest a rule here similar to what assignment
does to null AA:
If someone refers to an uninitialized null AA ( in
implementation, that maybe, a copy of a nu
On Thursday, 7 August 2014 at 18:05:15 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Aug 07, 2014 at 05:42:28PM +, via Digitalmars-d
wrote:
On Thursday, 7 August 2014 at 17:35:46 UTC, Puming wrote:
>So I'd like to suggest a rule here similar to what assignment
>does to
>null AA:
>
>If s
On Thursday, 7 August 2014 at 18:57:15 UTC, Andrei Alexandrescu
wrote:
One function we could and should use is one that makes an AA
that is empty but not null. Right now one needs to use goofy
methods such as adding and then removing a key. -- Andrei
https://issues.dlang.org/show_bug.cgi?id=
On Thursday, 7 August 2014 at 19:27:10 UTC, Ary Borenszweig wrote:
On 8/7/14, 3:57 PM, Andrei Alexandrescu wrote:
On 8/7/14, 10:35 AM, Puming wrote:
On Thursday, 7 August 2014 at 16:53:24 UTC, H. S. Teoh via
Digitalmars-d
It's really just the .init value of null which causes odd
behaviour with
On 8/7/14, 3:57 PM, Andrei Alexandrescu wrote:
On 8/7/14, 10:35 AM, Puming wrote:
On Thursday, 7 August 2014 at 16:53:24 UTC, H. S. Teoh via Digitalmars-d
It's really just the .init value of null which causes odd behaviour with
empty AA's. Fun fact:
void changeAA(int[string] aa) {
On 8/7/14, 10:35 AM, Puming wrote:
On Thursday, 7 August 2014 at 16:53:24 UTC, H. S. Teoh via Digitalmars-d
It's really just the .init value of null which causes odd behaviour with
empty AA's. Fun fact:
void changeAA(int[string] aa) {
aa["a"] = 123;
}
// Null AA:
int[st
On Thursday, 7 August 2014 at 18:05:15 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Aug 07, 2014 at 05:42:28PM +, via Digitalmars-d
wrote:
On Thursday, 7 August 2014 at 17:35:46 UTC, Puming wrote:
>So I'd like to suggest a rule here similar to what assignment
>does to
>null AA:
>
>If s
On Thu, Aug 07, 2014 at 05:42:28PM +, via Digitalmars-d wrote:
> On Thursday, 7 August 2014 at 17:35:46 UTC, Puming wrote:
> >So I'd like to suggest a rule here similar to what assignment does to
> >null AA:
> >
> >If someone refers to an uninitialized null AA ( in implementation,
> >that maybe
On Thursday, 7 August 2014 at 17:35:46 UTC, Puming wrote:
So I'd like to suggest a rule here similar to what assignment
does to null AA:
If someone refers to an uninitialized null AA ( in
implementation, that maybe, a copy of a null AA struct
happens), allocate it first.
I'm afraid that cop
On Thursday, 7 August 2014 at 16:53:24 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Aug 07, 2014 at 11:46:48AM +, via Digitalmars-d
wrote:
AAs are (like regular dynamic arrays) initialized to `null`.
On first
modification (i.e. assignment of an element), memory is
allocated and
the AA
On Thursday, 7 August 2014 at 16:53:24 UTC, H. S. Teoh via
Digitalmars-d wrote:
I'm not the one to make the decision, but I'd vote for
codifying this
behaviour in the language reference. From what I understand, at
least,
it seems that this is the intention anyway, and the current
implementation
On Thu, Aug 07, 2014 at 11:46:48AM +, via Digitalmars-d wrote:
> AAs are (like regular dynamic arrays) initialized to `null`. On first
> modification (i.e. assignment of an element), memory is allocated and
> the AA variable updated to point at it.
>
> However, is there a guarantee that AAs ar
AAs are (like regular dynamic arrays) initialized to `null`. On
first modification (i.e. assignment of an element), memory is
allocated and the AA variable updated to point at it.
However, is there a guarantee that AAs are never reallocated once
they are initialized, i.e. is it then safe to as
13 matches
Mail list logo
