• maarten van damme (17/17) Apr 17 2012 Just for fun I decided to complete some codejam challenges in D. At some
• simendsjo (13/31) Apr 17 2012 Sounds like a bug. C style initializers work in other cases:
• bearophile (5/6) Apr 17 2012 D language is so much irregular, so many special cases that don't
• Kenji Hara (10/47) Apr 17 2012 No, it is designed. {3,5} is struct initializer:
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (17/18) Apr 17 2012 I try not to use them. I think they have this 'feature' of leaving
• Kenji Hara (6/24) Apr 18 2012 You should use std.math.isNaN whether a floating point value is
• maarten van damme (2/2) Apr 18 2012 That's a very odd design. Making it work when instantiating a new struct...
• Somedude (6/8) Apr 18 2012 It's not odd at all. You append a structure, not an array.
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (5/9) Apr 18 2012 That a thousandth time I have made that mistake and still have not
• bearophile (4/7) Apr 18 2012 Today I'll present an enhancement request to remove this problem from D.
• SomeDude (2/10) Apr 18 2012 I don't see how this could be enhanced.
• Jonathan M Davis (5/18) Apr 18 2012 It's by design. An enhancement request is a waste of time. Comparisons w...
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (6/24) Apr 18 2012 - even
• SomeDude (2/15) Apr 18 2012 Now THAT makes sense.
• H. S. Teoh (5/20) Apr 18 2012 +1.
• bearophile (5/11) Apr 18 2012 That's what my proposal is going to be, with small refinements
• Jonathan M Davis (6/36) Apr 18 2012 Yes, that would make sense. Heck, I'd be tempted to argue that using == ...
• bearophile (5/11) Apr 18 2012 Take a look here:

maarten van damme <maartenvd1994 gmail.com> writes:

Just for fun I decided to complete some codejam challenges in D. At some
point I wanted to add structs to an array but I got a compiler error. What
am I doing wrong?

code:
struct test{
int x;
int y;
}
void main(){
test[] why;
why~={3,5};
}

error:
wait.d(7): found '}' when expecting ';' following statement
wait.d(8): found 'EOF' when expecting ';' following statement
wait.d(8): found 'EOF' when expecting '}' following compound statement

Is there any reason a why this wouldn't work?

simendsjo <simendsjo gmail.com> writes:

On Tue, 17 Apr 2012 22:28:31 +0200, maarten van damme  
<maartenvd1994 gmail.com> wrote:

 Just for fun I decided to complete some codejam challenges in D. At some
 point I wanted to add structs to an array but I got a compiler error.  
 What
 am I doing wrong?

 code:
 struct test{
 int x;
 int y;
 }
 void main(){
 test[] why;
 why~={3,5};
 }

 error:
 wait.d(7): found '}' when expecting ';' following statement
 wait.d(8): found 'EOF' when expecting ';' following statement
 wait.d(8): found 'EOF' when expecting '}' following compound statement

 Is there any reason a why this wouldn't work?

Sounds like a bug. C style initializers work in other cases:

struct S { int i; }
void main() {
     S[] arr;
     S s = { 1 };
     arr ~= S(1);
     // But the following barfs
     //arr ~= { 1 };
     //arr ~= { i:1 };
     //arr[0] = { 1 };
}

"bearophile" <bearophileHUGS lycos.com> writes:

simendsjo:

 Sounds like a bug. C style initializers work in other cases:

D language is so much irregular, so many special cases that don't 
work :-)

Bye,
bearophile

"Kenji Hara" <k.hara.pg gmail.com> writes:

On Tuesday, 17 April 2012 at 21:00:55 UTC, simendsjo wrote:
 On Tue, 17 Apr 2012 22:28:31 +0200, maarten van damme 
 <maartenvd1994 gmail.com> wrote:

 Just for fun I decided to complete some codejam challenges in 
 D. At some
 point I wanted to add structs to an array but I got a compiler 
 error. What
 am I doing wrong?

 code:
 struct test{
 int x;
 int y;
 }
 void main(){
 test[] why;
 why~={3,5};
 }

 error:
 wait.d(7): found '}' when expecting ';' following statement
 wait.d(8): found 'EOF' when expecting ';' following statement
 wait.d(8): found 'EOF' when expecting '}' following compound 
 statement

 Is there any reason a why this wouldn't work?

 Sounds like a bug. C style initializers work in other cases:

 struct S { int i; }
 void main() {
     S[] arr;
     S s = { 1 };
     arr ~= S(1);
     // But the following barfs
     //arr ~= { 1 };
     //arr ~= { i:1 };
     //arr[0] = { 1 };
 }

No, it is designed. {3,5} is struct initializer:
http://dlang.org/declaration.html#StructInitializer
And it is only allowed in initializer of variable declarations.

 why~={3,5};

This is concat assign expression, so you should use test(3,5)
instead of {3,5}. That is StructLiteral:
http://dlang.org/struct.html#StructLiteral
and it is an expression.

Bye.

Kenji Hara

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 04/17/2012 02:00 PM, simendsjo wrote:

 Sounds like a bug. C style initializers work in other cases:

I try not to use them. I think they have this 'feature' of leaving 
unspecified members uninitialized:

struct S
{
     int i;
     double d;
}

void main()
{
     S s = { 42 };               // <-- no initializer for S.d
     assert(s.i == 42);
     assert(s.d == double.nan);  // <-- fails (may work for you)
}

Is that a bug or a feature? I might have opened it but I don't remember 
now. :)

Ali

"Kenji Hara" <k.hara.pg gmail.com> writes:

On Wednesday, 18 April 2012 at 04:55:23 UTC, Ali Çehreli wrote:
 On 04/17/2012 02:00 PM, simendsjo wrote:

 Sounds like a bug. C style initializers work in other cases:

 I try not to use them. I think they have this 'feature' of 
 leaving unspecified members uninitialized:

 struct S
 {
     int i;
     double d;
 }

 void main()
 {
     S s = { 42 };               // <-- no initializer for S.d
     assert(s.i == 42);
     assert(s.d == double.nan);  // <-- fails (may work for you)

You should use std.math.isNaN whether a floating point value is 
NaN.

       assert(isNaN(s.d));  // <-- success

 }

 Is that a bug or a feature? I might have opened it but I don't 
 remember now. :)

 Ali

Bye.

Kenji Hara

maarten van damme <maartenvd1994 gmail.com> writes:

That's a very odd design. Making it work when instantiating a new struct of
that type but not inline. Anyway, test(3,5) works perfect, thank you.

Somedude <lovelydear mailmetrash.com> writes:

Le 18/04/2012 12:41, maarten van damme a écrit :
 That's a very odd design. Making it work when instantiating a new struct
 of that type but not inline. Anyway, test(3,5) works perfect, thank you.

It's not odd at all. You append a structure, not an array.
{3,5} is for array initialization, it's the same syntax as in C, C++,


What if you want to append an array of structures ?

    why~=[test(3,5), test(3,6)];

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 04/18/2012 12:16 AM, Kenji Hara wrote:
 On Wednesday, 18 April 2012 at 04:55:23 UTC, Ali Çehreli wrote:

 assert(s.d == double.nan); // <-- fails (may work for you)

 You should use std.math.isNaN whether a floating point value is NaN.

 assert(isNaN(s.d)); // <-- success

That a thousandth time I have made that mistake and still have not 
learned. :( Yes, .nan may not be compared with any other value, 
including .nan.

Ali

bearophile <bearophileHUGS lycos.com> writes:

Ali: 
 That a thousandth time I have made that mistake and still have not 
 learned. :( Yes, .nan may not be compared with any other value, 
 including .nan.

Today I'll present an enhancement request to remove this problem from D.

Hugs,
bearophile

"SomeDude" <lovelydear mailmetrash.com> writes:

On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote:
 Ali:
 That a thousandth time I have made that mistake and still have 
 not learned. :( Yes, .nan may not be compared with any other 
 value, including .nan.

 Today I'll present an enhancement request to remove this 
 problem from D.

 Hugs,
 bearophile

I don't see how this could be enhanced.

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Wednesday, April 18, 2012 19:04:12 SomeDude wrote:
 On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote:
 Ali:
 That a thousandth time I have made that mistake and still have
 not learned. :( Yes, .nan may not be compared with any other
 value, including .nan.

 
 Today I'll present an enhancement request to remove this
 problem from D.
 
 Hugs,
 bearophile

 
 I don't see how this could be enhanced.

It's by design. An enhancement request is a waste of time. Comparisons with 
NaN _always_ return false regardless of what they're compared against - even 
NaN. It's not going to change.

- Jonathan M Davis

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 04/18/2012 10:13 AM, Jonathan M Davis wrote:
 On Wednesday, April 18, 2012 19:04:12 SomeDude wrote:
 On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote:
 Ali:
 That a thousandth time I have made that mistake and still have
 not learned. :( Yes, .nan may not be compared with any other
 value, including .nan.

 Today I'll present an enhancement request to remove this
 problem from D.

 Hugs,
 bearophile

 I don't see how this could be enhanced.

 It's by design. An enhancement request is a waste of time. 

Comparisons with
 NaN _always_ return false regardless of what they're compared against 

- even
 NaN. It's not going to change.

 - Jonathan M Davis

It shouldn't be a problem to detect comparisons against literal .nan 
values. The compiler can warn with "comparison is always false".

Ali

"SomeDude" <lovelydear mailmetrash.com> writes:

On Wednesday, 18 April 2012 at 18:18:44 UTC, Ali Çehreli wrote:
 On 04/18/2012 10:13 AM, Jonathan M Davis wrote:
 It's by design. An enhancement request is a waste of time.

 Comparisons with
 NaN _always_ return false regardless of what they're compared

 against - even
 NaN. It's not going to change.

 - Jonathan M Davis

 It shouldn't be a problem to detect comparisons against literal 
 .nan values. The compiler can warn with "comparison is always 
 false".

 Ali

Now THAT makes sense.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Wed, Apr 18, 2012 at 08:50:10PM +0200, SomeDude wrote:
 On Wednesday, 18 April 2012 at 18:18:44 UTC, Ali Çehreli wrote:
On 04/18/2012 10:13 AM, Jonathan M Davis wrote:
 It's by design. An enhancement request is a waste of time.
 Comparisons with NaN _always_ return false regardless of what
 they're compared against - even NaN. It's not going to change.

 - Jonathan M Davis

It shouldn't be a problem to detect comparisons against literal .nan
values. The compiler can warn with "comparison is always false".

Ali

 
 Now THAT makes sense.

+1.


T

-- 
"Computer Science is no more about computers than astronomy is about
telescopes." -- E.W. Dijkstra

"bearophile" <bearophileHUGS lycos.com> writes:

SomeDude:

 It shouldn't be a problem to detect comparisons against 
 literal .nan values. The compiler can warn with "comparison is 
 always false".

 Ali

 Now THAT makes sense.

That's what my proposal is going to be, with small refinements 
:-) (And it think it's not the first time someone proposes it).

Bye,
bearophile

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Wednesday, April 18, 2012 11:18:44 Ali Çehreli wrote:
 On 04/18/2012 10:13 AM, Jonathan M Davis wrote:
 On Wednesday, April 18, 2012 19:04:12 SomeDude wrote:
 On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote:
 Ali:
 That a thousandth time I have made that mistake and still have
 not learned. :( Yes, .nan may not be compared with any other
 value, including .nan.

 
 Today I'll present an enhancement request to remove this
 problem from D.
 
 Hugs,
 bearophile

 
 I don't see how this could be enhanced.

 
 It's by design. An enhancement request is a waste of time.

 
 Comparisons with
 
 NaN _always_ return false regardless of what they're compared against

 
 - even
 
 NaN. It's not going to change.
 
 - Jonathan M Davis

 
 It shouldn't be a problem to detect comparisons against literal .nan
 values. The compiler can warn with "comparison is always false".

Yes, that would make sense. Heck, I'd be tempted to argue that using == with 
floating point values in general should be a warning, since that's pretty much 
never what you actually want, but that's probably not going to fly.

But the behavior itself isn't going to change.

- Jonathan M Davis

"bearophile" <bearophileHUGS lycos.com> writes:

SomeDude:

 Today I'll present an enhancement request to remove this 
 problem from D.

 Hugs,
 bearophile

 I don't see how this could be enhanced.

Take a look here:
http://forum.dlang.org/thread/undjpdewiqmghmhndedw forum.dlang.org

Bye,
bearophile