Unknown W. Brackets wrote:
> This is why, to my understanding:
> 
> struct foo
> {
>    int x, y;
> }
> struct bar
> {
>    int x, y;
> }
> 
> void foobar(foo f)
> {
> }
> 
> void foobar(bar b)
> {
> }
> 
> int main()
> {
>    foobar({0, 0});
> 
>    return 0;
> }
> 
> Which one does it call?
<snip top of upside-down reply>

That's not the meaning of the word "initializer".

An initializer is something that follows the '=' in a declaration, as in the OP's code.  This is syntactically, and to some extent semantically, distinct from an expression.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

True, but he asked why and I answered; as far as I understand, that is why they are illegal.  Initializers themselves are not hampered by this problem, but likely it is waiting for a solution to the overall problem.

-[Unknown]


> That's not the meaning of the word "initializer".
> 
> An initializer is something that follows the '=' in a declaration, as in the OP's code.  This is syntactically, and to some extent semantically, distinct from an expression.
> 
> Stewart.
> 

Unknown W. Brackets wrote:
> True, but he asked why and I answered; as far as I understand, that is why they are illegal.

Your comment had exactly nothing to do with why the OP's code is invalid.

    static A a={5,10};

isn't ambiguous, so how can

    A b={5,10};

possibly be ambiguous?

> Initializers themselves are not hampered by this problem, but likely it is waiting for a solution to the overall problem.
<snip top of upside-down reply>

AIUI the only pending difficulty in adding struct/array literals is deciding on the syntax.  If this is the case, there is nothing impeding the above notation (already _syntactically_ valid, and unambiguous) from being legalised.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> AIUI the only pending difficulty in adding struct/array literals is deciding on the syntax.  If this is the case, there is nothing impeding the above notation (already _syntactically_ valid, and unambiguous) from being legalised.

It should also be possible to decide on a valid D syntax,
long before it is actually implemented ? As it is now, the
language spec is rather closely tied to the reference compiler...

Similar goes for other peeves, like the return value of main.
Wouldn't hurt to have it at least "defined", even if not enforced
or implemented by the current compilers. Like a todo list, or roadmap.


And I wouldn't mind seeing a "looser coupling" between:
- D, the language specication
- D, the reference compiler (DMD)
- D, the standard library (Phobos)

I think it would also help alternative compilers like GDC,
and alternative libraries like the one from the Ares project.
But maybe this is something for "after the release", or so ?

But it's somewhat annoying to not know what _year_ that will be... :-P

--anders

But, as I said, why have two syntaxes?  Because you like Perl, or just because you want the langauge to be confusing?

-[Unknown]


> AIUI the only pending difficulty in adding struct/array literals is deciding on the syntax.  If this is the case, there is nothing impeding the above notation (already _syntactically_ valid, and unambiguous) from being legalised.

Unknown W. Brackets wrote:
> But, as I said, why have two syntaxes?

The struct initialiser syntax was obviously designed to look like that of C.  However, it isn't suitable for general use in expressions because of the ambiguity you mentioned.  But it's a neat-looking syntax nonetheless.  And so Walter obviously saw fit to follow C's example by having two nonterminals, Initializer and Expression, each a superset of AssignExpression.

> Because you like Perl, or just because you want the langauge to be
> confusing?
<snip top of upside-down reply>

What's confusing about it?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.