"Patrick Down" <pat@codemoon.com> wrote in message news:Xns92AC9CA96B771patcodemooncom@63.105.9.61...
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in news:aos9ij$2ht8$1@digitaldaemon.com:
> > I'm wondering if someone will explain to me again what the logic is behind not allowing constructors for structs?
> I think that Walter beleves that adding contructors will create
> a chain reaction leading to people wanting destructors
> and copy constructors for structs.

Constructors for structs will produce a string, that when pulled, will force the inclusion of copy constructors and assignment operator overloading, both of which there's good reason to avoid.

Well then can we at least have syntax sugar for calling initializer functions from the declaration?

mystruct a.init(x,y,z);

But then what about sending a new struct object to a function?

DrawLine(Point(x1,y1), Point(x2,y2), Color(255,0,0,255));

I read somewhere not long ago (think it was in Lakos) that there's overlap in C++ between:

            destroy  init    copy
ctor                   X
copy ctor              X       X
assign         X       X       X
dtor           X

you can make assignment out of the dtor plus the copy ctor
Or, you can ideally break it down into the 3 main operations:  init, copy, destroy

Data is more than the sum of its bits.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ap32mr$96b$1@digitaldaemon.com...
> 
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns92AC9CA96B771patcodemooncom@63.105.9.61...
> > "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in news:aos9ij$2ht8$1@digitaldaemon.com:
> > > I'm wondering if someone will explain to me again what the logic is behind not allowing constructors for structs?
> > I think that Walter beleves that adding contructors will create
> > a chain reaction leading to people wanting destructors
> > and copy constructors for structs.
> 
> Constructors for structs will produce a string, that when pulled, will force the inclusion of copy constructors and assignment operator overloading, both of which there's good reason to avoid.

Those are good ideas to think about.
  "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ap40qg$39k$1@digitaldaemon.com...
  Well then can we at least have syntax sugar for calling initializer functions from the declaration?

  mystruct a.init(x,y,z);

  But then what about sending a new struct object to a function?

  DrawLine(Point(x1,y1), Point(x2,y2), Color(255,0,0,255));

  I read somewhere not long ago (think it was in Lakos) that there's overlap in C++ between:

              destroy  init    copy
  ctor                   X
  copy ctor              X       X
  assign         X       X       X
  dtor           X

  you can make assignment out of the dtor plus the copy ctor
  Or, you can ideally break it down into the 3 main operations:  init, copy, destroy

  Data is more than the sum of its bits.

  Sean

  "Walter" <walter@digitalmars.com> wrote in message news:ap32mr$96b$1@digitaldaemon.com...
  >
  > "Patrick Down" <pat@codemoon.com> wrote in message
  > news:Xns92AC9CA96B771patcodemooncom@63.105.9.61...
  > > "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in
  > > news:aos9ij$2ht8$1@digitaldaemon.com:
  > > > I'm wondering if someone will explain to me again what the logic is
  > > > behind not allowing constructors for structs?
  > > I think that Walter beleves that adding contructors will create
  > > a chain reaction leading to people wanting destructors
  > > and copy constructors for structs.
  >
  > Constructors for structs will produce a string, that when pulled, will force
  > the inclusion of copy constructors and assignment operator overloading, both
  > of which there's good reason to avoid.