Re: default formal parameters in generic declarations

[Eric Hughes <eric.eh9@gmail.com>]

On Mar 4, 11:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Looking back at the old
> minutes, we had a straw poll where about half of the people present thought
> that this feature was not important enough. That's a pretty significant
> number

I can understand why so many people did not understand the
significance of this feature.  I know I would not have then.  It
wasn't until just the last two years or so that I've done any really
significant generic programming in C++.  Let me begin to rectify that
deficiency in understanding its significance.

The real difficulty with not have package defaults begins the second
layer of generic instantiation, not the first.  For just one layer (by
that I mean a simple instantiation of a generic) it's certainly easy
enough to put in a default manually.  But what then if the package in
which this happens is itself generic, and, furthermore, incurs a
dependency of this instantiation on its own formal parameters?  This
is the completely typical case, to pick an example, for a generic
package "A" that's configurable with a storage pool.  Another generic
package "B" should (in most cases), as a matter of information hiding,
also have a storage pool parameter of its own that it forwards to
package "A" at its instantiation, but should also allow a different
storage pool for "A".  (I don't know why you'd want this insofar as
storage pools go, but they're just the example parameter here.)
Without a default formal parameter, there is no way to get both of the
following desiderata simultaneously:
    1. Forwarding of the "B" parameter to "A" and elision of a
duplicate parameter when these are the same.
    2. Ability to override the forward and specify a separate
parameter in "B" for use in "A".
You can get 1 by just hard-coding the instantiation parameter for "B",
but that eliminates 2.  You can get 2 by using an extra parameter in
"B", but that eliminates the second half of 1.

Even with just two layer of instantiation this is feasible, but, in
the phrase I used earlier, "horribly klunky" (particularly with non-
linear references).  So here's the biggest problem: You cannot get
simultaneously both arbitrarily deep layering and concision in formal
parameters for ordinary usage.  Without defaults, every single
ordinary usage has the same notational complexity as an arbitrary
usage in full generality.  This severely limits the practical utility
of generic programming in Ada to simple cases.  And I say that
anything that limits the depth of abstraction layering is a _prima
facie_ bad thing.  It breaks information hiding in a bad way.

As a coda, I wish to add that this practice is not hypothetical.  The
sophistication of some of the generic (template) programming in the
Boost C++ library is excellent and worth imitating.