The most obvious limitations have already been mentioned: functoids in FC++ are only supported for up to three arguments, and functoid parameters always have value semantics. In practice so far, the three-argument limit has not been an issue. There are no technical reasons that the framework cannot be extended to accomodate additional arguments if this is deemed valuable.

The choice of "value semantics" arguably requires some justification. Most functional languages are "by value", and indeed in many functional languages, most (if not all) objects are immutable, which makes reference semantics unnecessary. While reference parameters for functoids could be supported by FC++, these would complicate the implementation and provide no extra utility within FC++ (due to the absence of lvalues). Unfortunately, the choice of "value semantics" sometimes makes it hard to interface FC++ to extant C++ code that utilizes references. Simply put, FC++ was not designed with cases like these in mind, and thus (like all tools) FC++ is not the best tool for every job.

Functional programmers who desire a more technical discussion of the limitations of FC++ compared to functional programming languages and type systems should read Section 8 of [McN&Sma to appear]. It should also be noted that FC++ provides no support for the creation of algebraic datatypes or for pattern matching.

FC++ also does not provide any kind of "tuple" datatype. The commonest case, 2-tuples, are adequately met by std::pair. Users wanting a more general tupling mechanism should use boost::tuples.

As mentioned in Section 15, the "lambda" and "monad" portions of the library use expression templates, which can seriously degrade compile-time performance. Clients which make heavy use of lambda and monads take a long time to compile and require a lot of memory. Hopefully, in time, C++ compilers will get better at compiling expression-template code.

Finally, this document could use some improvement. Two things are notably absent: some medium-sized examples demonstrating the utility of the library, and an initial motivating example. One of the challenges of presenting such examples well is choosing the application domain—as described in Section 14, FC++ can be applied to a variety of domains. (If you have suggestions for improvement here, please let Brian know.)

Over time, the FC++ library has grown and evolved a lot in order to meet the needs of its users. Though we consider the bulk of the implementation infrastructure complete, there are still a number of interesting future directions to consider. These include

By all means, if you have feature requests for FC++, contact the authors—especially in cases where you already have a real client application which demonstrates the need.