C++ reference type

[Tom S]

David Medlock wrote:
> Tom S wrote:
>> You could with classes, but in this case typeof(arr4[0]) is a struct.
>>
> 
> I meant in the case you returned a pointer,

Ah.. sorry then ;)


> but yes that wouldn't follow 
> the 'native' array semantics so it wouldn't be good to return a pointer. 
>  Maybe with the static if you could make your container behave different 
> with non-object types?

That's the approach I've proposed some time ago to someone implementing 
a custom container class. Not very consistent, but if there's nothing 
better at the moment...


> It just hasn't bit me a lot thus far (and I have written a fair amount of code in D)
> I don't see a clear solution short of reference/inout returns, but I wonder what
> that would do to the rest of the language semantics.

I've had a few occasions to miss this feature from C++ ...

I'm not sure if reference return types would be very hard to implement 
in the compiler, but a good syntax would have to be developed and 
probably the 'inout' keyword wouldn't cut it, e.g.

void foo (inout int function());

Does foo take an inout function pointer or does it take a function that 
returns an int by reference ?

Putting 'inout' after the basic type could work, e.g.

void foo(int inout function());

but then it's inconsistent with void bar(inout int x);

If it was supposed to be consistent in this case, that 'bar' decl would 
have to become 'void bar(int inout x)'... but it doesn't read fine. But 
then renaming inout to 'ref' would make it sound ok again, e.g.

void bar(int ref x)
void foo(int ref function());

but then I wouldn't see a point in not using the '&' token instead.

What would it do to other semantics ? Not much, I guess, but people 
would want references everywhere and not only for return and parameter 
types :P


>> Ummm... no, thanks :P
>>
> 
> Tongue in cheek example of course, but I'm so far liking the delegate 
> syntax.

It's not *very* bad, but I've got no idea what performance consequences 
it yields.


> We aren't really disagreeing on any implementation details, only on 
> their impact on daily use.

True. I don't want it to done like in C++, but at least *something* 
ought to be done. E.g. to make various custom containers seem more like 
built-ins.



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/