Exactly Replicating a Function's Signature?

[Andrej Mitrovic]

On 1/19/11, %u <wfunction at hotmail.com> wrote:
>> Is this what you're looking for?:
>
> No. :)
> (Though you already found this out at the end!)
> I was looking for some way to keep the storage classes and any other
> (meta)data
> about the parameters that may be added in the future to the library. I have
> a
> feeling this might be a very big change in how DMD handles parameters, but
> without
> this feature, perfect redirection -- which I think is possible in C++0x --
> would
> be impossible in D.
>
> My suggestion would be that we treat "ref", "out", and "lazy" as type
> constructors
> rather than storage specifiers; that way, we could get rid of the concept of
> storage classes entirely, and it would unify the concept of references with
> other
> languages like C# and C++.
>
> How does this idea sound? :) (I think it's easier said than done, though...)
>

Let me see if I get this straight (correct me if I'm wrong in
understanding this).
So you mean we would have e.g. ref as a type constructor:
ref int x;

The problem with this is that now you're functions look like this:
foo(int x) { }

You can't tell if foo modifies x just by looking at the signature. You
would have to look at the calling site to find out which arguments
were passed, and then you'd have to look at their declaration. (well,
unless you use an IDE of some sort that does this automatically, it's
2011 I guess.. :-) ).

Having "in", "ref", "out".. in function parameters helps in
understanding your own code. If you look at e.g. Microsoft header
files there are a lot of methods named like so:

foo(/*in*/ param1, /*in*/ param2, /*out*/ param3)

D just took this existing practice and made it a language feature.

Anyway, I don't know of a workaround for the full signature problem.
For a second I thought about using a string mixin, but mixins can't be
used inside the function signatures, so I can't just glue together
"ref" and "int".