Exactly Replicating a Function's Signature?

%u wfunction at hotmail.com
Wed Jan 19 20:37:59 PST 2011

> The ugly solution would be to do this:
> void test (ref int a) { }
> void main () { writeln(typeof(&test).stringof); }
> Which will print: "void function(ref int a)" and then parse out what you need.

If you're referring to using mixin() to parse the signature, I've already thought
of that, but it won't work because if the type of any parameter is a user-defined
type, it will be inaccessible outside the module that provides this facility. This
feature will require compiler and/or language modification(s); I don't believe you
can add the storage-class feature correctly with the current language (though
please correct me if I'm wrong).

> 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) { }

No... why? ref would be just like const -- so your parameter's data type could be
ref(const(string)). Why do you say the functions remove the type constructor from
the header?

[This is a bit unrelated, but while we're on the topic of documenting code through
ref/out: I think it would be better if the language required the "ref" and "out"
keywords on passing the parameters, like C# does... it prevents a lot of bugs that
can happen when a function's header is changed, since now the caller code won't
compiler, instead of compiling but working potentially incorrectly.)

I actually noticed a different problem with treating storage classes as type
constructors: while "ref" and "lazy" would work well, "out" would make no sense as
a type constructor, so this solution probably won't work at all.

Does anyone have any ideas on how to get storage classes to work correctly with
ParameterTypeTuple, whether or not it's a dirty solution (so long as the solution

More information about the Digitalmars-d-learn mailing list