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
