Does D have too many features?

[Jonathan M Davis]

On Sunday, April 29, 2012 10:07:38 David Nadlinger wrote:
> On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis
> 
> wrote:
> > But even just storing it in a local variable to use later
> > could destroy the locality enough to defeat LDC's optimization.
> 
> Huh? I can't think of a situation where a hash table lookup would
> entail less indirections than dereferencing a pointer stored in a
> register (resp. the stack, depending on scheduling).

If you have something like

if(key in aa)
{
    // lots of code
    func(aa[key]);
}

the compiler is not necessarily going to be able to determine that the AA has 
not been changed such that aa[key] can use the same lookup that key in aa did 
rather than redoing the lookup. A prime example would be

if(key in aa)
{
    foo(aa);
    func(aa[key]);
}

The compiler doesn't necessarily know that foo won't remove key from aa, so it 
can't save the result of key in aa to reuse rather than calling aa[key], 
whereas the programmer could know that foo doesn't do anything to aa which 
would make a pointer to the element invalid and can guarantee that only one 
lookup occurs by doing

if(auto value = key in aa)
{
    foo(aa);
    func(value);
}

And that's just one case where the compiler can't make such an optimization 
but the programmer can. It's _far_ better iMHO to have in return a pointer 
than to rely on the compiler removing extraneous lookups.

- Jonathan M Davis