Not a naming suggestion, but a suggestion for a guideline on how to chose names: make it simpler for most users.
If we still want one million users: 1. Most of them will never bother with std.allocator (by which I don't mean it is not necessary!) 2. Of those relatively few using std.allocator, most will use the canned, easy-to-use, high-level stuff 3. Just a few users will reach the plumbing. As someone personally prefering to remain in group 1 forever, but I willing to visit group 2 occasionally if necessary, I'd prefer to simply say import std.allocator; and get access to the higher-level stuff instead of import std.allocator.whatever; This has implications even for the hypothetical day in which I'll be required to use std.allocator. The closer to the root I find the stuff I need (that is, the high-level stuff), the quicker I'll find it. If I find lower-level stuff before finding the higher-level ones, I might even be fooled to believe that I don't have better (better for me) alternatives, and start a path of unnecessary suffering. The bottom line: please make the naming reflect the expected usage, taking into account the mythical one million users. Simpler names for the stuff that will be used by most of us. Cheers, LMB On Fri, May 15, 2015 at 12:27 AM, Andrei Alexandrescu via Digitalmars-d < [email protected]> wrote: > Ready for yet another name debate? Here's an opportunity! > > I just added: > > > http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html > > > https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d > > It's very useful, but it seems the name doesn't do it justice. > > Also, I need two more good names: one for what's now called "porcelain" - > high-level typed interface for allocators, and one for "best of Beatles" > (not defined yet) - a module collecting a number of canned good allocator > designs by connecting together components. > > > Thanks, > > Andrei >
