Arcane Jill wrote:

> Actually, auto does a lot more than that.

Of course, but again, that's only has to do with auto variables, not with auto classes. I don't doubt the usefulness of auto variables (any more), but auto classes really seem like an unnecessary restriction. Why shouldn't the class user be mature enough to decide in which way he wants to ensure that the object is explicitely deleted?

>>Anyhow: declaring a class in a way that forces the user to use auto on variables may very well prevent legitimate uses. Like in the case of your file-handle: what if the user wants to open a file for longer than just one routine? You would have to create a different class for that purpose!
> 
> Not really. You can almost always design your program in such a way that every resource exists only within a given scope. I've always found that to be a very useful device to encourage good design.

That depends very much on the design of your program. Window handles in an interactive program, can not easily be restricted to only one function. This is even more generally true for interactive programs of any kind. Network connections or pipes, for example, would also live for a long time, while the program should do something else in between.

Your comparison to C++-objects on the stack is very legitimate, anyhow, it also shows that in many cases, objects on the stack are not appropriate for a certain purpose.

> If you want to pass the embedded filehandle (or whatever) around, you can
> still do that with getter function (in D, a property).

Is it possible to embed auto members in a class, or what?

>>Maybe, it would be a better idea to introduce the concept of "resource classes", i.e. classes that hold resources (like file handles, locks, network connections, windows or whatever). These files would then have to be deleted explicitely. What strategy the user takes to ensure the explicit deletion is up to him. "auto" variables would just be one option among others. If the GC finds such a class as garbage, it would throw an error. If such a class still exists when the program ends, it is an error as well.
> 
> That's feasible. I don't know how much work it would be for Walter though. But auto *carries out* the delete without your having to make that deletion explicit, so I still like it.

Exactly! "auto" as a variable modifier. But not "auto" as an artificial restriction on a class!

Stewart Gordon wrote:
> J C Calvarese wrote:
> <snip>
> 
>> Incidently, I've come up with an example that shows how an auto is different than a non-auto class:
>> http://www.dsource.org/tutorials/index.php?show_example=75
> 
> <snip>
> 
> Where does that page have anything to do with auto _classes_ whatsoever?
> 
> Stewart.

Pardon me, I missed the gist of the OP's question. I'm sorry if the example wasn't particular pertinent, but I thought that perhaps someone would find it useful. It does happen to show the creation of an _auto_ instance of a _class_.

If you find no use _whatsoever_ in my examples, it won't hurt my feelings if you feel free to ignore them.

I'm trying to be helpful. I suppose I've been trying too hard. I'll try less in the future.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/