Is

    key in aa ? aa[key] : ValueType.init;

the most efficient way to maybe return a value from an associative array aa?

On Thursday, 8 January 2015 at 15:45:27 UTC, Nordlöw wrote:
> Is
>
>     key in aa ? aa[key] : ValueType.init;
>
> the most efficient way to maybe return a value from an associative array aa?

aa.get(key, ValueType.init)

On Thursday, 8 January 2015 at 15:49:46 UTC, Dragos Carp wrote:
> On Thursday, 8 January 2015 at 15:45:27 UTC, Nordlöw wrote:
>> Is
>>
>>    key in aa ? aa[key] : ValueType.init;
>>
>> the most efficient way to maybe return a value from an associative array aa?
>
> aa.get(key, ValueType.init)

That was too easy ;)

It would be nice if the compiler could detect usage of aa.get() automatically and issue either a diagnostics or transform it in an optimization pass.

On Thu, 08 Jan 2015 15:59:10 +0000
"Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Thursday, 8 January 2015 at 15:49:46 UTC, Dragos Carp wrote:
> > On Thursday, 8 January 2015 at 15:45:27 UTC, Nordlöw wrote:
> >> Is
> >>
> >>    key in aa ? aa[key] : ValueType.init;
> >>
> >> the most efficient way to maybe return a value from an associative array aa?
> >
> > aa.get(key, ValueType.init)
> 
> That was too easy ;)
> 
> It would be nice if the compiler could detect usage of aa.get() automatically and issue either a diagnostics or transform it in an optimization pass.
how can it? compiler doesn't know what the code is supposed to do. if compilers will know such things someday, we can stop writing programs altogether, as compilers will be able to write any program for us. ;-)

On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote:
> how can it? compiler doesn't know what the code is supposed to do. if
> compilers will know such things someday, we can stop writing programs
> altogether, as compilers will be able to write any program for us. ;-)

Correction:

I thought it would be nice if the compiler explained to me that

    key in aa ? aa[key]

is a sub-optimal performance-wise.

On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote:
> On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote:
>> how can it? compiler doesn't know what the code is supposed to do. if
>> compilers will know such things someday, we can stop writing programs
>> altogether, as compilers will be able to write any program for us. ;-)
>
> Correction:
>
> I thought it would be nice if the compiler explained to me that
>
>     key in aa ? aa[key]
>
> is a sub-optimal performance-wise.

You know, that you kan reuse the result of the in operator by AAs?

example:

auto ptr = key in aa;
ptr ? *ptr : ValueType.init

On Friday, January 09, 2015 00:20:07 Foo via Digitalmars-d-learn wrote:
> On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote:
> > On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote:
> >> how can it? compiler doesn't know what the code is supposed to
> >> do. if
> >> compilers will know such things someday, we can stop writing
> >> programs
> >> altogether, as compilers will be able to write any program for
> >> us. ;-)
> >
> > Correction:
> >
> > I thought it would be nice if the compiler explained to me that
> >
> >     key in aa ? aa[key]
> >
> > is a sub-optimal performance-wise.
>
> You know, that you kan reuse the result of the in operator by AAs?
>
> example:
>
> auto ptr = key in aa;
> ptr ? *ptr : ValueType.init

This idiom is quite common:

if(auto ptrToValue = key in aa)
{
}

though I'm not sure that that quite fits in with what Nordlow seems to be trying to do with init. aa.get probably does a better job of that, though looking at the implementation for get, it's basically doing what you're suggesting:

auto p = key in aa;
return p ? *p : defaultValue;

though that has the downside of using a lazy parameter for the default value, which is convenient but doesn't do great things for performance.

- Jonathan M Davis

On Thu, 08 Jan 2015 23:06:38 +0000
"Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote:
> > how can it? compiler doesn't know what the code is supposed to
> > do. if
> > compilers will know such things someday, we can stop writing
> > programs
> > altogether, as compilers will be able to write any program for
> > us. ;-)
> 
> Correction:
> 
> I thought it would be nice if the compiler explained to me that
> 
>      key in aa ? aa[key]
> 
> is a sub-optimal performance-wise.
although it's right in most cases, it's still implying that compiler is able to understand the code behind `in` and `[key]`, as they aren't built into the compiler, but rather coded in druntime. producing warning on such code can create wrong impression about compiler code analysing abilities.

this time i think that it's a work for a linter, 'cause there is nothing wrong with the code, it's just a questionable style. so let linter question it. ;-)

On Friday, 9 January 2015 at 06:18:53 UTC, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Friday, January 09, 2015 00:20:07 Foo via Digitalmars-d-learn wrote:
>> On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote:
>> > On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via
>> > Digitalmars-d-learn wrote:
>> >> how can it? compiler doesn't know what the code is supposed to
>> >> do. if
>> >> compilers will know such things someday, we can stop writing
>> >> programs
>> >> altogether, as compilers will be able to write any program for
>> >> us. ;-)
>> >
>> > Correction:
>> >
>> > I thought it would be nice if the compiler explained to me that
>> >
>> >     key in aa ? aa[key]
>> >
>> > is a sub-optimal performance-wise.
>>
>> You know, that you kan reuse the result of the in operator by AAs?
>>
>> example:
>>
>> auto ptr = key in aa;
>> ptr ? *ptr : ValueType.init
>
> This idiom is quite common:
>
> if(auto ptrToValue = key in aa)
> {
> }
>
> though I'm not sure that that quite fits in with what Nordlow seems to be
> trying to do with init. aa.get probably does a better job of that, though
> looking at the implementation for get, it's basically doing what you're
> suggesting:
>
> auto p = key in aa;
> return p ? *p : defaultValue;
>
> though that has the downside of using a lazy parameter for the default
> value, which is convenient but doesn't do great things for performance.
>
> - Jonathan M Davis
I just wasn't sure that he knows about it.

On Friday, January 09, 2015 07:51:27 Foo via Digitalmars-d-learn wrote:
> On Friday, 9 January 2015 at 06:18:53 UTC, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Friday, January 09, 2015 00:20:07 Foo via Digitalmars-d-learn wrote:
> >> You know, that you kan reuse the result of the in operator by AAs?
> >>
> >> example:
> >>
> >> auto ptr = key in aa;
> >> ptr ? *ptr : ValueType.init
> >
> > This idiom is quite common:
> >
> > if(auto ptrToValue = key in aa)
> > {
> > }
> >
> > though I'm not sure that that quite fits in with what Nordlow
> > seems to be
> > trying to do with init. aa.get probably does a better job of
> > that, though
> > looking at the implementation for get, it's basically doing
> > what you're
> > suggesting:
> >
> > auto p = key in aa;
> > return p ? *p : defaultValue;
> >
> > though that has the downside of using a lazy parameter for the
> > default
> > value, which is convenient but doesn't do great things for
> > performance.
> >
> > - Jonathan M Davis
> I just wasn't sure that he knows about it.

Oh, he might not have known about it (certainly, the fact that he called in and then [] in his origanal code implies that he didn't), and it was definitely useful to tell him. My point was simply that get applies better for his use case than using in directly. In general though, in is of _far_ more use than [], precisely because it combines asking whether the element is there and getting it into one command. Personally, I pretty much never use [] on AAs.

- Jonathan M Davis