Walter Bright wrote:
> Struct constructors!
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.035.zip
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.019.zip

Thanks!

Also, thanks for identifying all the bugs fixed now instead of later, it makes it much easier to track my issues :)

-Steve

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Struct constructors! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.035.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.019.zip

What does a struct constructor in its current form make possible/easy that was awkward/impossible with opCalls?

dsimcha wrote:
> What does a struct constructor in its current form make possible/easy that was
> awkward/impossible with opCalls?

Aside from the logical symmetry, it enables an object to be constructed using operator new.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> dsimcha wrote:
> > What does a struct constructor in its current form make possible/easy that was awkward/impossible with opCalls?
> Aside from the logical symmetry, it enables an object to be constructed using operator new.

In that case, struct ctors are a nice addition, but please don't deprecate opCall.
 I personally think it's fine to just make them mutually exclusive.

Walter Bright wrote:
> Struct constructors!

Must... have... D2.  :-)

By the way, no runtime changes were required to upgrade Tango to work with this release, so Tango users can drop in the new DMD without any issues.


Sean

Sean Kelly wrote:
> Walter Bright wrote:
>> Struct constructors!
> 
> Must... have... D2.  :-)

I figured you'd be seduced sooner or later!

bobef wrote:
> opCalls are much more flexible than ctor's because their return type may
> vary or they may not have return type. I vote against deprecating them. Let
> whoever likes ctors use them and whoever likes opCalls use these.

I agree opCalls are more flexible, but unfortunately you can't have both
because of syntactical ambiguity... :-(

regards, 0ffh

Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Struct constructors!
>>
>> Must... have... D2.  :-)
> 
> I figured you'd be seduced sooner or later!

So this would make structs (in effect) classes that don't exist on the heap?

Chris R. Miller wrote:
> Walter Bright wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>> Struct constructors!
>>> Must... have... D2.  :-)
>> I figured you'd be seduced sooner or later!
> 
> So this would make structs (in effect) classes that don't exist on the heap?
> 

No, structs do not inherit and do not have virtual functions.

On Wed, Sep 3, 2008 at 4:30 PM, 0ffh <frank@youknow.what.todo.internetz>wrote:

> bobef wrote:
>
>> opCalls are much more flexible than ctor's because their return type may
>> vary or they may not have return type. I vote against deprecating them.
>> Let
>> whoever likes ctors use them and whoever likes opCalls use these.
>>
>
> I agree opCalls are more flexible, but unfortunately you can't have both because of syntactical ambiguity... :-(
>
> regards, 0ffh
>

Speaking of syntactical ambiguity, the expression

S(1, 2, 3)

can, right now, have one of three meanings:

1. A struct literal for struct S
2. A call to S's static opCall
3. An instantiation of S and a call to its ctor

Even if opCall goes away, we'll still be left with the ambiguity of struct literal vs. ctor.  I'd really, really like to hear Walter's view on this but he has responded neither to the thread I posted on digitalmars.D nor the bugzilla ticket (http://d.puremagic.com/issues/show_bug.cgi?id=2170).