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
