little typo:
writefln("f(%1$s) = %2$%", x, y);      --->     writefln("f(%1$s) = %2$s", x, y);

it doesn't compile anyway!

Walter, don't you think that the ctor overloading should be on "static opCall" better than *any* opCall?


Pablo Ripolles Wrote:

> 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.
> 

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.
> 

This is one of those things I really dislike about D :(
It's really nice that we can override struct initialization, but the fact that it eliminates the possibility to override it (with a nice syntax) makes it much less appealing IMHO.

The most important point to me, is that old thing about static struct initializer and struct literals have different syntaxes, and that the static variant is much more flexible.

I would have loved to see the static struct initializer syntax become an expression. If the problem is ambiguity, why not just prefix the {} braces with the struct name?

struct S
{
 int a;
 float b;
}

const s = S{1, 2.0};
const t = S{b:3.14};

void foo()
{
 auto st = S{4,5.5};
}

(also not that it's currently impossible to use type inference with the current static struct initializers)

This would eliminate the gripe most people have with this I think, as well as making static and  non-static initializers consistent. like they are *for all other types*.

I can't help feel structs (like static arrays) aren't first class citizens in D. Even with the latest additions in D2. It hurts, and is just one of those small reasons why I sometimes regret I even joined this community...

My 2 cents on this, I think it's a big mistake going against the wishes of the D community. If I'm wrong, let me know.

-Tomas

On Thu, 04 Sep 2008 15:44:30 +0400, Tomas Lindquist Olsen <tomas@famolsen.dk> 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.
>>
>
> This is one of those things I really dislike about D :(
> It's really nice that we can override struct initialization, but the fact that it eliminates the possibility to override it (with a nice syntax) makes it much less appealing IMHO.
>
> The most important point to me, is that old thing about static struct initializer and struct literals have different syntaxes, and that the static variant is much more flexible.
>
> I would have loved to see the static struct initializer syntax become an expression. If the problem is ambiguity, why not just prefix the {} braces with the struct name?
>
> struct S
> {
>   int a;
>   float b;
> }
>
> const s = S{1, 2.0};
> const t = S{b:3.14};
>
> void foo()
> {
>   auto st = S{4,5.5};
> }
>

It may have problems with the q{}:

struct q
{
    float t;
}

auto foo = q{ t = 3.1415f };	// what's the type of foo?

But then, does anybody using it?

Other than that I agree, current solution is not very good.

> (also not that it's currently impossible to use type inference with the current static struct initializers)
>
> This would eliminate the gripe most people have with this I think, as well as making static and   non-static initializers consistent. like they are *for all other types*.
>
> I can't help feel structs (like static arrays) aren't first class citizens in D. Even with the latest additions in D2. It hurts, and is just one of those small reasons why I sometimes regret I even joined this community...
>
> My 2 cents on this, I think it's a big mistake going against the wishes of the D community. If I'm wrong, let me know.
>
> -Tomas



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Thu, Sep 4, 2008 at 7:44 AM, Tomas Lindquist Olsen <tomas@famolsen.dk> wrote:

> The most important point to me, is that old thing about static struct initializer and struct literals have different syntaxes, and that the static variant is much more flexible.
>
> I would have loved to see the static struct initializer syntax become an expression. If the problem is ambiguity, why not just prefix the {} braces with the struct name?
>
> struct S
> {
>  int a;
>  float b;
> }
>
> const s = S{1, 2.0};
> const t = S{b:3.14};
>
> void foo()
> {
>  auto st = S{4,5.5};
> }
>
> (also not that it's currently impossible to use type inference with the current static struct initializers)
>
> This would eliminate the gripe most people have with this I think, as well as making static and  non-static initializers consistent. like they are *for all other types*.

Now were you just reading off of http://d.puremagic.com/issues/show_bug.cgi?id=2170 or did you come to this conclusion independently ;)

Jarrett Billingsley wrote:
> 
> Now were you just reading off of
> http://d.puremagic.com/issues/show_bug.cgi?id=2170 or did you come to
> this conclusion independently ;)

Actually, I've never read that report before :P
Seriously !!

But it looks like we pretty much agree ...

Glad I'm not alone here ;)

-Tomas

Denis Koroskin wrote:
> 
> It may have problems with the q{}:
> 
> struct q
> {
>     float t;
> }
> 
> auto foo = q{ t = 3.1415f };    // what's the type of foo?
> 
> But then, does anybody using it?
> 
> Other than that I agree, current solution is not very good.
> 

A valid point, I can think of lots of other ways to provide this specific feature though. I'd also guess that struct literals are much more common than tokenized strings...

So... I don't think this is a valid reason to dismiss this!

On Thu, Sep 4, 2008 at 7:58 AM, Denis Koroskin <2korden@gmail.com> wrote:
> On Thu, 04 Sep 2008 15:44:30 +0400, Tomas Lindquist Olsen <tomas@famolsen.dk> 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.
>>>
>>
>> This is one of those things I really dislike about D :(
>> It's really nice that we can override struct initialization, but the fact
>> that it eliminates the possibility to override it (with a nice syntax) makes
>> it much less appealing IMHO.
>>
>> The most important point to me, is that old thing about static struct initializer and struct literals have different syntaxes, and that the static variant is much more flexible.
>>
>> I would have loved to see the static struct initializer syntax become an expression. If the problem is ambiguity, why not just prefix the {} braces with the struct name?
>>
>> struct S
>> {
>>  int a;
>>  float b;
>> }
>>
>> const s = S{1, 2.0};
>> const t = S{b:3.14};
>>
>> void foo()
>> {
>>  auto st = S{4,5.5};
>> }
>>
>
> It may have problems with the q{}:
>
> struct q
> {
>    float t;
> }
>
> auto foo = q{ t = 3.1415f };    // what's the type of foo?
>
> But then, does anybody using it?
>
> Other than that I agree, current solution is not very good.
>

auto foo = q { t: 3.1415f}; // typeof(foo) == q

q{ is treated more or less as an atomic character.  Put a space between them and bam, you have a struct literal.

And please don't get rid of token strings; those of us who love mixins wouldn't want to see them go ;)

Jarrett Billingsley wrote:
> On Thu, Sep 4, 2008 at 7:58 AM, Denis Koroskin <2korden@gmail.com> wrote:
>> On Thu, 04 Sep 2008 15:44:30 +0400, Tomas Lindquist Olsen
>> <tomas@famolsen.dk> 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.
>>>>
>>> This is one of those things I really dislike about D :(
>>> It's really nice that we can override struct initialization, but the fact
>>> that it eliminates the possibility to override it (with a nice syntax) makes
>>> it much less appealing IMHO.
>>>
>>> The most important point to me, is that old thing about static struct
>>> initializer and struct literals have different syntaxes, and that the static
>>> variant is much more flexible.
>>>
>>> I would have loved to see the static struct initializer syntax become an
>>> expression. If the problem is ambiguity, why not just prefix the {} braces
>>> with the struct name?
>>>
>>> struct S
>>> {
>>>  int a;
>>>  float b;
>>> }
>>>
>>> const s = S{1, 2.0};
>>> const t = S{b:3.14};
>>>
>>> void foo()
>>> {
>>>  auto st = S{4,5.5};
>>> }
>>>
>> It may have problems with the q{}:
>>
>> struct q
>> {
>>    float t;
>> }
>>
>> auto foo = q{ t = 3.1415f };    // what's the type of foo?
>>
>> But then, does anybody using it?
>>
>> Other than that I agree, current solution is not very good.
>>
> 
> auto foo = q { t: 3.1415f}; // typeof(foo) == q
> 
> q{ is treated more or less as an atomic character.  Put a space
> between them and bam, you have a struct literal.
> 
> And please don't get rid of token strings; those of us who love mixins
> wouldn't want to see them go ;)

I kinda like

""{foobar etc}

as an alternative

Pablo Ripolles wrote:
> little typo: writefln("f(%1$s) = %2$%", x, y);      --->
> writefln("f(%1$s) = %2$s", x, y);
> 
> it doesn't compile anyway!
> 
> Walter, don't you think that the ctor overloading should be on
> "static opCall" better than *any* opCall?

That would make opCall overload unlike anything else.

Tomas Lindquist Olsen wrote:
> This is one of those things I really dislike about D :(
> It's really nice that we can override struct initialization, but the fact that it eliminates the possibility to override it (with a nice syntax) makes it much less appealing IMHO.
> 
> The most important point to me, is that old thing about static struct initializer and struct literals have different syntaxes, and that the static variant is much more flexible.
> 
> I would have loved to see the static struct initializer syntax become an expression. If the problem is ambiguity, why not just prefix the {} braces with the struct name?

The static struct initializers more or less are inherited from C. I'd eventually like to abandon them and go completely to the S(args) syntax.