I have been thinking about the optimal manner in which we can work with implementing the intrinsic functions at compile time. This is a preliminary RFC (request for comments) which might be of interest to all the recent contributors as well; pinging @certik, @Thirumalai-Shaktivel, @czgdp18071 and @dpoe (apologies if I missed anyone).

Currently we have two implementations; a switch statement on the number of arguments (symboltable) and an ifelse setup (body visitor).

Moving forward I would prefer the ifelse since many of the functions take an optional set of arguments. This will then live inside the CommonVisitor and use unordered_map to lookup which one should be called. So far so good.

However, more importantly, there are two ways moving forward, with classes or with partial functions.

Classes

In this approach we'd have a base virtual class with:

• name Function name
• n_rargs Required arguments
• n_oargs Optional arguments
• implementation This is the name of the implementation (pure fortran, openlibm etc.) and is used to resolve the symbol at runtime

Derived classes would simply implement (an overloaded) operator() with the implementation.

Pros

• Conceptually simple
• Flexible
• RAII

Cons

• Slow??
• Overkill??

Partial Function

In this approach, we would use std::bind to simplify which one of the functions would be used (based on the number of arguments) and the appropriate function pointer will be called out of the map.

Pros

• Shorter?
• Easier to inline implementations

Cons

• Not very C++ like perhaps?

Thoughts

As can be seen; this is a very rough draft, comments are welcome and appreciated.