The 'auto' idea was looking more and more like a way to simply put class objects on the stack. Ok, so I smack my forehead, and think why not allow destructors for structs? This would provide the automatic destruction of structs when they go out of scope. Some other properties talked about with auto are implicit with structs:

1) they cannot be derived from or inherited
2) the 'auto' is implicit
3) can't implicitly convert to Object

Furthermore, to make things easier, the following can be disallowed:

1) arrays of structs with destructors
2) structs with destructors as class or struct fields
3) assignment of structs with destructors

A class can be 'auto-ized' by wrapping it in a struct:

    struct AutoA
    {    A a;
        ~this() { delete a; }
    }

and can even be templatized:

    template AutoClass(T)
    {
        T t;
        ~this() { delete t; }
    }

"Walter" <walter@digitalmars.com> wrote in news:akgsaf$aog$1@digitaldaemon.com:


> 3) assignment of structs with destructors

struct Foo
{
  ~this() { }
}


void Bar(Foo a)
{
}


Foo a;
Bar(a); // Is this allowed?

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9277B119511Bpatcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:akgsaf$aog$1@digitaldaemon.com:
> > 3) assignment of structs with destructors
> struct Foo
> {
>   ~this() { }
> }
> void Bar(Foo a)
> {
> }
> Foo a;
> Bar(a); // Is this allowed?

No. I should add that copy-initializers are not allowed, either.

That sounds like a fine plan.

I don't see how any of your second 3 points (to make things easier) would seem daunting to someone like you who has implemented a C++ compiler or three.  ;)

They seem like simple enough concepts.  What do you find so difficult about it?  Seems templates and exceptions are far more of a challenge.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:akgsaf$aog$1@digitaldaemon.com...
> The 'auto' idea was looking more and more like a way to simply put class objects on the stack. Ok, so I smack my forehead, and think why not allow destructors for structs? This would provide the automatic destruction of structs when they go out of scope. Some other properties talked about with auto are implicit with structs:
>
> 1) they cannot be derived from or inherited
> 2) the 'auto' is implicit
> 3) can't implicitly convert to Object
>
> Furthermore, to make things easier, the following can be disallowed:
>
> 1) arrays of structs with destructors
> 2) structs with destructors as class or struct fields
> 3) assignment of structs with destructors
>
> A class can be 'auto-ized' by wrapping it in a struct:
>
>     struct AutoA
>     {    A a;
>         ~this() { delete a; }
>     }
>
> and can even be templatized:
>
>     template AutoClass(T)
>     {
>         T t;
>         ~this() { delete t; }
>     }

"Walter" <walter@digitalmars.com> wrote in news:akh8id$p90$1 @digitaldaemon.com:

> 
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9277B119511Bpatcodemooncom@63.105.9.61...
>> "Walter" <walter@digitalmars.com> wrote in news:akgsaf$aog$1@digitaldaemon.com:
>> > 3) assignment of structs with destructors
>> struct Foo
>> {
>>   ~this() { }
>> }
>> void Bar(Foo a)
>> {
>> }
>> Foo a;
>> Bar(a); // Is this allowed?
> 
> No. I should add that copy-initializers are not allowed, either.
> 
> 

With the previous method I could.

auto fload = new File(name);

LoadObjects(fload);


Now it looks like I need to do this...

instance AutoClass(File) AutoFile;

AutoFile fload;

fload.t = new File(name);

LoadObjects(fload.t);

If you put constructors on structs too then
it could work like this.

struct AutoFile
{
  File f;
  this(char[] name)
  {
    f = new File(name);
  }
  ~this()
  {
    if(f) f.close();
  }
}

Autofile fload(name);

LoadObjects(fload.f);

You're right. I know supporting struct constructors is an attractive notion, but I'd like to try avoiding them for the moment.

Making them work is a substantial increase in the complexity of the compiler, bugs in the compiler (!), attempting to explain to programmers all the noise going on behind the scenes for something simple-appearing like passing a struct value to a function, etc. It brings to the fore confusing notions like the difference between assignment and initialization, overloading assignment operators and copy constructors start becoming necessary, etc.

In short, many things I was trying to leave behind <g>.

If the territory can be covered without needing that stuff, I sure want to give it a try.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns927810D18195Dpatcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:akh8id$p90$1 @digitaldaemon.com:
>
> >
> > "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9277B119511Bpatcodemooncom@63.105.9.61...
> >> "Walter" <walter@digitalmars.com> wrote in news:akgsaf$aog$1@digitaldaemon.com:
> >> > 3) assignment of structs with destructors
> >> struct Foo
> >> {
> >>   ~this() { }
> >> }
> >> void Bar(Foo a)
> >> {
> >> }
> >> Foo a;
> >> Bar(a); // Is this allowed?
> >
> > No. I should add that copy-initializers are not allowed, either.
> >
> >
>
> With the previous method I could.
>
> auto fload = new File(name);
>
> LoadObjects(fload);
>

Every problem can be solved by adding a level of indirection.

auto fload = new File(name);
LoadObjects(&fload);

If File is a struct you should not pass it by value, but by address.

"Walter" <walter@digitalmars.com> wrote in news:akgsaf$aog$1@digitaldaemon.com:

> The 'auto' idea was looking more and more like a way to simply put class objects on the stack. Ok, so I smack my forehead, and think why not allow destructors for structs? This would provide the automatic destruction of structs when they go out of scope. Some other properties talked about with auto are implicit with structs:
> 
> 1) they cannot be derived from or inherited
> 2) the 'auto' is implicit
> 3) can't implicitly convert to Object
> 
> Furthermore, to make things easier, the following can be disallowed:
> 
> 1) arrays of structs with destructors
> 2) structs with destructors as class or struct fields
> 3) assignment of structs with destructors

I think I still like the auto idea better.

With the struct solution it seems like you would end
back at the old problem of having duplicate class
and struct variants of the same objects.

As you suggest we can wrap a class reference in a struct. However this just seems like a more complicated version of the auto keyword.

Yes, my gut feeling is that the struct solution causes more problems than it solves.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]