Return by 'ref' problems...

[Andrei Alexandrescu]

On 5/15/12 8:16 AM, Manu wrote:
> Okay, here's another problem due to ref not being a type constructor.
> If I have some function that receives an argument by ref, and then I
> take parameterTypeTuple! of that functions parameter list, the ref bits
> are gone from the typetuple.
> If I give that tuple as a template arg, then the template parameters no
> longer match the function it's wrapping...

Correct. That means there needs to be an additional trait that tells 
which parameters of a function are ref.

> I'm still thinking more and more that there's no solution to all the
> problems with ref, other than changing it to use the syntax: ref(type),
> and be a type constructor, like const/immutable/shared/etc...
> I have problems with ref almost every day. If not in templates, in
> function/delegate definitions, and the prior issues previously discussed..
>
> No matter how I look at it, 'ref' really should be a type constructor.

Ref on a parameter or the return value is a property of the function, 
not a property of the parameter.

> The use of 'ref' fundamentally changes the variable from T to T*, that's
> a critical difference, and can't just be lost when taking the typeof
> something.

Ref int is not int*, for example you can do x[0 .. 1] on a pointer but 
not on a reference. Ref fundamentally dictates how the parameter binds 
to the argument; otherwise, it doesn't affect the behavior of the 
parameter's type itself.

To lift this one level up, what problem are you trying to solve?


Andrei