Return by 'ref' problems...

[Gor Gyolchanyan]

There's ParameterStorageClassTuple, which can say if it's a pointer-type
parameter (ref and out) or it's a delegate-type parameter (lazy). By
analyzing the storage classes of the parameters, one can transform T to T*
or T delegate() as necessary.

Indeed I did precisely this, when I wrote a function parameter tuple
encapsulator. It's a template, which takes a function signature and returns
a structure, which has an appropriate member for each parameter (taking
into account ref, out and lazy) and can call functions of that signature by
passing the stored parameters.


On Tue, May 15, 2012 at 5:28 PM, Andrei Alexandrescu <
SeeWebsiteForEmail at erdani.org> wrote:

> 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
>



-- 
Bye,
Gor Gyolchanyan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120515/1de63c43/attachment.html>