Bruno Medeiros wrote:
> Ok, I don't think I made my point correctly. Yes, it's useful to distinguish between virtual, static and final member functions[*], but that's something that could be done (if not already) with is-expressions. What I mean is more about this:
> "An important rule of function overloading works in our favor, here: A given function symbol can only refer to functions which are all virtual, all static, or all final."
> Why would we want this change?
> 

I had somehow been mistaken that this was the way it worked currently. Whoops.

Since this isn't true, the StaticExpression syntax would have to specify the particular overload to operate on, something like:

StaticExpression:
    static ( Symbol Type == SymbolSpecialization )

Where Type is the signature of the overload to operate on, as in:

class C {
    void foo() {}
    static void foo(int i) {}
}

static(C.foo void function() == virtual) // true
static(C.foo void function(int) == static) // true

Specifying an non-existent overload should probably be an error.

> 
> [*] Although, I'm not so sure about virtual vs. final distinctions.
> 

As I said, this distintion may be important if you're doing certain tricks with inheritance. And if these mechanisms are being added, I don't think there's any reason /not/ to add it.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

I understand the need of reflection t connect D to other languages.
Still I think that a solution to this problem should be (not necessarily now, but in the future) extensible to template functions.

The virtual/final/static attributes seem quite straightforward and unproblematic (I like the is(x==virtual) solution because it is what I would have expected).
The symbol+signature -> function pointer is also unproblematic (be it through an alias cast or assignment).
The symbol -> signatures thing can be problematic if templates enter in the picture.

One could think of representing all kind of signatures by allowing things like
template(TemplateType T0){template(alias T1){template(int T2){template(int T3){T0 function(T0[T2],optional T0[T3])}
or something like it.
Unfortunately this is not enough as there is no guarantee that a given template is instantiable.
Instantiability can be controlled at compile time, but still for automatic interface generators one cannot avoid giving them some extra information.

One could think about giving restricting the list of signatures either to full specializations (and maybe have some hint that extra ones might exist), or to the templates that have been instantiated (but such a set is not fixed and can change from program to program).

In any case some thought should be spent about this.

Fawzi

We offer World of Warcraft Power Leveling and World of Warcraft powerleveling,Final Fantasy XI Gil,Maple Story and Lord fo Ring Online Powerleveling.WoW Powerleveling service and cheap wow Powerleveling,World of Warcraft Power leveling sale for you. WOW Power leveling,Cheap WOW Powerleveling 1-60 and Cheap WOW Powerleveling 1 - 70.All service is faster,safer,and cheaper.WOW Powerleveling 1 - 60,WOW Powerleveling 1 - 70.Lord fo Ring Online Power Leveling 1-50 .We Please remember,we are your online game helper.pvpsale