On Wed, Sep 3, 2008 at 9:47 PM, Bill Baxter <wbaxter@gmail.com> wrote:
> On Thu, Sep 4, 2008 at 10:38 AM, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:
>> On Wed, Sep 3, 2008 at 8:22 PM, Moritz Warning <moritzwarning@web.de> wrote:
>>>
>>> On Wed, 03 Sep 2008 20:04:49 -0400, Jarrett Billingsley wrote:
>>>
>>> > On Wed, Sep 3, 2008 at 7:29 PM, Walter Bright <newshound1@digitalmars.com>wrote:
>>> >
>>> >> Jarrett Billingsley wrote:
>>> >>
>>> > Otherwise, it&#39;s a struct literal.<br> </blockquote></div><br>So uh,<br><br>why don&#39;t you want to change struct literals?<br><br></div>
>>>
>>> Hi Jarrett,
>>> do you mind not to use html markup?
>>> My news reader has no html renderer, nor my eye to brain connection.
>>> Thanks. :)
>>
>> Ack, I've started using the mailing lists and gmail to interact with the newsgroups and forgot that it uses HTML by default, thanks for the heads up.
>>
>
> That happened to me too.
>
> I posted a suggestion to Google after that that Gmail should be smart
> enough not to reply to a plain text message with an HTML formatted
> one.  Or that there should be a way to specify certain recipients
> don't get HTML.
> Maybe if you suggest it too it will push it up on their radar a bit.
>
> --bb
>

I think I was the one who pointed it out to you, making my transgression more than inexcusable ;)

I'll let them know.

Jarrett Billingsley wrote:
> why don't you want to change struct literals?

See my reply to bearophile

Ary Borenszweig wrote:
> So both syntax are possible?
> 
> S(...)

Creates a struct instance

> new S(...)

Creates a struct instance and returns a pointer to it.

在 Thu, 04 Sep 2008 09:23:08 +0800，のしいか (noshiika) <noshiika@gmail.com> 写道:

> Walter Bright wrote:
>> Struct constructors!
>
> Thanks for the nice release!
>
> I have a question. The "dynamic initialization of struct" syntax seems
> still using opCall. Is it going to replaced by constructors?
>
>      struct S {
>          this(int x) {
>              writeln("ctor");
>          }
>          static S opCall(int x) {
>              writeln("opCall");
>              return S.init;
>          }
>      }
>
>      void main(){
>          S s = 1; // prints "opCall"
>      }

umm, another bug ?

-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

"Walter Bright" wrote
> Ary Borenszweig wrote:
>> So both syntax are possible?
>>
>> S(...)
>
> Creates a struct instance
>
>> new S(...)
>
> Creates a struct instance and returns a pointer to it.

On the heap I assume? (hope)

-Steve

Walter Bright Wrote:

> bearophile wrote:
> > Walter Bright:
> >> If there's any constructor defined for S, then S(args) is a
> >> constructor call. If there's any opCall defined for S, then S(args)
> >> is an opCall call. Otherwise, it's a struct literal.
> > 
> > I haven't tried that in real code, so I can't be sure, but while it may work for the compiler, it sounds a bit too much complex for the person that later reads the code. Too many alternative possibilities may make the code more complex to follow.
> > 
> > To reduce such ambiguity (ambiguity for the person, not for the compiler) may be to change the syntax of struct literals...
> 
> I disagree, I think just the reverse. The S(args) syntax means that it's entirely up to the struct designer to say how it should work. The user needn't know or care, and the struct designer can change the design without affecting user code.
> 

And why not "new S(args)" to call the constructor (which is natural so far) and "S(args)" to work as it does now?

bobef wrote:
> Walter Bright Wrote:
> 
>> bearophile wrote:
>>> Walter Bright:
>>>> If there's any constructor defined for S, then S(args) is a
>>>> constructor call. If there's any opCall defined for S, then S(args)
>>>> is an opCall call. Otherwise, it's a struct literal.
>>> I haven't tried that in real code, so I can't be sure, but while it
>>> may work for the compiler, it sounds a bit too much complex for the
>>> person that later reads the code. Too many alternative possibilities
>>> may make the code more complex to follow.
>>>
>>> To reduce such ambiguity (ambiguity for the person, not for the
>>> compiler) may be to change the syntax of struct literals...
>> I disagree, I think just the reverse. The S(args) syntax means that it's entirely up to the struct designer to say how it should work. The user needn't know or care, and the struct designer can change the design without affecting user code.
>>
> 
> And why not "new S(args)" to call the constructor (which is natural so far) and "S(args)" to work as it does now?

How would you distinguish between allocating the struct on the heap and on the stack? "new" anything does heap allocation and returns a pointer/reference, so it would be inconsistent if it did stack allocation for structs (plus, then you'd have to manually allocate the heap memory & copy the struct over... ew).

class C { }
struct S { }

int* i = new int; // Heap allocates
C c = new C; // Heap allocates
S* s = new S; // Heap allocates

Steven Schveighoffer wrote:
> "Walter Bright" wrote
>> Ary Borenszweig wrote:
>>> So both syntax are possible?
>>>
>>> S(...)
>> Creates a struct instance
>>
>>> new S(...)
>> Creates a struct instance and returns a pointer to it.
> 
> On the heap I assume? (hope)

S() creates it on the stack, new S() on the heap.

On Thu, Sep 4, 2008 at 2:21 PM, Robert Fraser <fraserofthenight@gmail.com> wrote:
>>
>> And why not "new S(args)" to call the constructor (which is natural so
>> far) and "S(args)" to work as it does now?
>
> How would you distinguish between allocating the struct on the heap and on the stack? "new" anything does heap allocation and returns a pointer/reference, so it would be inconsistent if it did stack allocation for structs

Except for scope of course:

scope foo = new Foo();

But I would guess for consistency that

scope sfoo = new StructFoo();

should return a pointer to a stack-allocated struct.

--bb

Sorry, but this is already somewhere else, I don't know why but I get my responses out of thread...

Walter Bright Wrote:

> Jarrett Billingsley wrote:
> > 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).
> 
> If there's any constructor defined for S, then S(args) is a constructor call.
> 
> If there's any opCall defined for S, then S(args) is an opCall call.

shouldn't this be so only for the static opCall's?

shouldn't this be possible?


///////////////////////////////////////////////////////

import std.stdio;


struct Parabola
{
    float a_;

    this(float a)
    {
        a_ = a;
    }

    float opCall(float x)
    {
        return a_ * x*x;
    }
}


void main()
{
    Parabola f;
    float x, y;

    f = Parabola(1.0);
    x = 2.0;
    y = f(x);

    writefln("f(%1$s) = %2$%", x, y);
}


///////////////////////////////////////////////////////


Thanks!

> 
> Otherwise, it's a struct literal.