Lazy range of hashes?

[Ali Çehreli]

On 08/26/2012 12:55 AM, Era Scarecrow wrote:
 > On Sunday, 26 August 2012 at 07:29:13 UTC, Ali Çehreli wrote:
 >> Cool! :) If the operator returns the pointer to the element, then the
 >> callers can access its value as well
 >
 > Reminds me, although not for you Ali, but as a pointer return a question
 > came up. I've wondered and haven't tested this but hypothetically:
 >
 > Due to that you can call structures and class members even from a
 > pointer (transparently compared to C/C++),

It has been argued that the -> operator has not been needed for C anyway.

Interestingly, it has some value in C++ because if a type has defined 
operator->() (rather, for this discussion, operator.(), which does not 
exist in C++ today), then the following would cause confusion for types 
that worked like smart pointers:

class P
{
     /* hypothetical operator */
     T * operator.();
     void foo();
};

     P p = bar();
     p.foo(); // foo() of the pointer type or the 'pointed to type'?

D does not have that question because the dot operator may not be 
overloaded. (opDot() has been (will be?) deprecated.)

 > does it automatically convert
 > from a pointer to a non-pointer type if the return calls for it?

No: The dot does not convert the type. The dot has different meanings on 
structs vs. classes. With structs, it always operates on the struct object:

     o.sizeof   // The size of the struct object
     o.foo()    // The member of the struct object

With classes, it operates sometimes on the reference and sometimes on 
the referenced object:

     o.sizeof   // The size of the class reference
     o.foo()    // The member of the class object

That's D's way of confusing on this topic.

 > In a
 > class that's irrelevant (it's already a reference type and should
 > auto-fix itself); But a struct or non-class?
 >
 > //just to get the idea
 > //potentially ref int, rather than int* as well
 > int getSomeValue(int[string] x, string someValue) {
 > auto sv = someValue in x;
 > return x ? x : 0; //auto convert? Or error? If not, why?

You meant sv:

     return sv ? sv : 0;

That is still a compilation error for a statically-typed language like 
D. The types of sv and 0 don't match. But the line should always be like 
this anyway:

     return sv ? *sv : 0;

Because sv is always a pointer:

   // For a struct pointer:
   *sv  // a reference to the struct object

   // For a class reference:
   *sv is another reference to the actual class object

 > Rather than auto could ref work?

You mean, 'ref' on the return type, right? For opIn_r, it better not be 
'ref', because then it would be returning a reference to a local pointer:

     // Note ref return. I think this is a bug.
     ref opIn_r(X)(X x)
     {
         foreach (hash; hashes)
         {
             auto p = x in hash;
             if (p)
                 return p; // <-- return a reference to the local pointer
         }

         return null;
     }

I think that is a bug but the compiler does not give a warning about 
returning a reference to the local pointer.

 > Or if it's a exact valueType (with
 > postblitz) or (known to be relocatable) would it make a new copy? I can
 > see the importance of both, but depending on the return type in cases,
 > having it throw an error seems like the best policy if it's a non-built
 > in, since it's trivial changing return x, with return *x; Also as a
 > built in type it could automatically do the copy/conversion for you.

As you said, returning *x would return a copy of the value if it were a 
struct.

Ali