[cfe-dev] PATCH: C++ Function Overloading (v2)

Doug Gregor doug.gregor at gmail.com
Mon Oct 20 17:21:33 PDT 2008


Hi Argiris,

On Thu, Oct 16, 2008 at 11:35 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> I recently thought about overload resolution again and I have some
> questions.
> While I understand the necessity of the OverloadType, is
> OverloadedFunctionDecl really necessary ?

We certainly need some way to represent the notion of an expression
that refers to an overloaded function; that's a basic notion in C++,
because name lookup can return a set of overloaded functions. Maybe it
could be something other than a DeclRefExpr that references an
OverloadedFunctionDecl.

> It seems to me that overload resolution is part of semantic analysis (the
> Sema), and OverloadedFunctionDecl is like implementation details of Sema
> "leaking" into the AST.
> OverloadedFunctionDecl will primarily be used by Sema, and expressions
> referencing it will get replaced and resolved to one FunctionDecl except
> probably when the expression is part of a template.

Templates will need to store sets of overloaded functions.

> In the case that the AST clients get an expression referencing
> OverloadedFunctionDecl, it's unlikely that it will be useful to them,
> without getting it resolved by the same semantic analysis as that of Sema's.

I can think of two kinds of clients that might want or need to deal
with OverloadedFunctionDecls.

First of all, any clients that are focused on parsing and don't need
to do much semantic analysis could certainly skip overload resolution,
and would therefore leave the OverloadedFunctionDecls in place since
they don't need to be resolved.

Second, clients that want to do some kind of speculative overload
resolution would need to query the overloads that show up in the
overload set. For example, an IDE that tries to help with overload
resolution by showing options while you type. Type "f(17, " and it
shows you all of the f's that could still be called. This client needs
to be able to ask the AST or Sema (it's not clear which) which "f"'s
are available, and then ask Sema which ones are still callable.

None of these require the exact OverloadedFunctionDecl formulation in
my patch, but they are AST clients to consider.

> How about if a reference of overloaded function "f", results in a
> OverloadExpr (with OverloadType), that contains the "f" IdentifierInfo and a
> 'void*' opaque value meant to be used by Sema (or in general, the Action
> implementation that created the OverloadExpr) ?
> The advantage of this is that Sema has full control and flexibility over the
> overload resolution mechanism, e.g. it can change it completely and it will
> have no impact on the AST or the AST clients.

The representation of the set of overloaded functions doesn't really
have anything to do with the overload resolution mechanism. Overload
resolution has to pass over the set of overloaded functions found by
name lookup and build its own data structures, collect other functions
found via argument-dependent lookup, etc., so I think it is very
unlikely even that two different Semas would need different
representations of the set of overloaded functions.

The disadvantage of having the 'void*' opaque value is that it makes
ownership harder: how does this void* get deallocated, serialized, or
de-serialized?

  - Doug



More information about the cfe-dev mailing list