I quote from the description of <stretchy-vector> in the DRM:

"Because <stretchy-vector> is abstract and instantiable but has no specified subclasses, every implementation must provide one or more concrete subclass to instantiate. These concrete subclasses have no specified names, and their names are not exported by the Dylan module."

A similar paragraph occurs in several other places in the section on the built-in collection classes. Saying it's legal to call make on a particular abstract class but leaving undefined what you get when you call make seems kind of weird. One way of dealing with this is to have the standard library define suitable classes for these operations. I was hoping that's part of what's going on if someone's working on a standard library.

Andrew Shalit

This design is intentional. There's no reason for programmers to know how any particular implementation implements stretchy vectors.

Okay, okay, it feels like about thirty-seven people have all told me that there's no reason why I should know what I'm really getting back when I make a <stretchy-vector>. You're right! Uncle, already!

Remember again that I'm a C++ programmer who's never written a line of code in a dynamic language. My confusion here stemmed from the fact that you can't instantiate an abstract class in C++. I know you can do that in Dylan, but because of my background, I'm conditioned to wanting to know what I'm getting. It'd make a difference in C++.