Re: Why do some T.init evaluate to true while others to false?

2016-05-31 Thread Marc Schütz via Digitalmars-d-learn
On Monday, 30 May 2016 at 19:06:53 UTC, ArturG wrote: does this count? struct Foo { int x; float f; } void main() { Foo foo; if(foo is typeof(foo).init) "A: does'nt work".writeln; foo = Foo(); if(foo is typeof(foo).init) "B: works".writeln; } This one is a bug in DMD.

Re: Why do some T.init evaluate to true while others to false?

2016-05-30 Thread Alex Parrill via Digitalmars-d-learn
On Friday, 27 May 2016 at 15:49:16 UTC, ArturG wrote: On Friday, 27 May 2016 at 15:24:18 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 15:19:50 UTC, ArturG wrote: yes but i have to check for that when some one does Why? This is no different than if they set any of the other four

Re: Why do some T.init evaluate to true while others to false?

2016-05-30 Thread ArturG via Digitalmars-d-learn
On Friday, 27 May 2016 at 14:48:59 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 14:43:47 UTC, ArturG wrote: if(value is typeof(value).init) ... that still requiers a special case for floating points, arrays and optionally empty string literals. Have you tried? That should work

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread ArturG via Digitalmars-d-learn
On Friday, 27 May 2016 at 18:03:23 UTC, Steven Schveighoffer wrote: I didn't change the default. The default is to pick the first member and use that as the init value. I may not have even considered what foo.init might be when I was creating my enum. -Steve by default i ment this enum

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread Steven Schveighoffer via Digitalmars-d-learn
On 5/27/16 1:42 PM, ArturG wrote: On Friday, 27 May 2016 at 16:56:21 UTC, Steven Schveighoffer wrote: Why are you expecting it to be? Won't work for enums with first elements that are non-zero either: enum foo : int { bar = 1; } foo f; if(f) writeln("this will output too"); but by

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread ArturG via Digitalmars-d-learn
On Friday, 27 May 2016 at 16:56:21 UTC, Steven Schveighoffer wrote: Why are you expecting it to be? Won't work for enums with first elements that are non-zero either: enum foo : int { bar = 1; } foo f; if(f) writeln("this will output too"); -Steve but by default it works you just

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread Steven Schveighoffer via Digitalmars-d-learn
On 5/27/16 11:49 AM, ArturG wrote: On Friday, 27 May 2016 at 15:24:18 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 15:19:50 UTC, ArturG wrote: yes but i have to check for that when some one does Why? This is no different than if they set any of the other four billion possible values.

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread ArturG via Digitalmars-d-learn
On Friday, 27 May 2016 at 15:24:18 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 15:19:50 UTC, ArturG wrote: yes but i have to check for that when some one does Why? This is no different than if they set any of the other four billion possible values. What do you mean? operation on

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 27 May 2016 at 15:19:50 UTC, ArturG wrote: yes but i have to check for that when some one does Why? This is no different than if they set any of the other four billion possible values.

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread ArturG via Digitalmars-d-learn
On Friday, 27 May 2016 at 15:07:50 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 14:56:28 UTC, ArturG wrote: float f; if(f is float.init) "float init".writeln; f = float.nan; if(f is float.init) "float nan".writeln; You changed it to a value that isn't float.init, so of

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 27 May 2016 at 14:56:28 UTC, ArturG wrote: float f; if(f is float.init) "float init".writeln; f = float.nan; if(f is float.init) "float nan".writeln; You changed it to a value that isn't float.init, so of course it isn't going to match! float.nan and float.init are

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread ArturG via Digitalmars-d-learn
On Friday, 27 May 2016 at 14:48:59 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 14:43:47 UTC, ArturG wrote: if(value is typeof(value).init) ... that still requiers a special case for floating points, arrays and optionally empty string literals. Have you tried? That should work

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 27 May 2016 at 14:43:47 UTC, ArturG wrote: if(value is typeof(value).init) ... that still requiers a special case for floating points, arrays and optionally empty string literals. Have you tried? That should work in all cases.

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread ArturG via Digitalmars-d-learn
On Friday, 27 May 2016 at 09:25:55 UTC, Marc Schütz wrote: On Thursday, 26 May 2016 at 16:45:22 UTC, ArturG wrote: im just playing with this template[1] is there anything else i missed? (if you dont mind) it basically treats any T.init as false and skips the function/delegate and just returns

Re: Why do some T.init evaluate to true while others to false?

2016-05-27 Thread Marc Schütz via Digitalmars-d-learn
On Thursday, 26 May 2016 at 16:45:22 UTC, ArturG wrote: im just playing with this template[1] is there anything else i missed? (if you dont mind) it basically treats any T.init as false and skips the function/delegate and just returns type. [1] https://dpaste.dzfl.pl/d159d83e3167 If you

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread ArturG via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:51:39 UTC, Basile B. wrote: Oh, I'm so sorry ! I totally missed the point of the Q. float.nan is not a "unique" value. Several values verify "nan" (Look at std.math.isNan). So I suppose it's simpler to test for nullity. Though with the sign there's also two

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread Basile B. via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:48:18 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:34:50 UTC, ArturG wrote: On Thursday, 26 May 2016 at 15:29:52 UTC, Basile B. wrote: float.init is not equal to 0.0f. In D FP points values are initialized to nan (not a number). By the way for

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread Basile B. via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:34:50 UTC, ArturG wrote: On Thursday, 26 May 2016 at 15:29:52 UTC, Basile B. wrote: float.init is not equal to 0.0f. In D FP points values are initialized to nan (not a number). By the way for strings it works, it's like the array case I described in the

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread ArturG via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:38:55 UTC, Basile B. wrote: because nan is not 0 and that the shortcut for float is if (fpValue) <=> if (fpValue != 0) if (!fpValue)<=> if (fpValue == 0) There's no relation between the initializer and the shortcut. It's not because for some values the

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread ag0aep6g via Digitalmars-d-learn
On 05/26/2016 05:28 PM, ArturG wrote: On Thursday, 26 May 2016 at 15:25:26 UTC, ag0aep6g wrote: [...] What does it matter? You would have to create special cases for them. When? If you want to check if something is the .init value, compare against .init.

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread Basile B. via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:34:50 UTC, ArturG wrote: On Thursday, 26 May 2016 at 15:29:52 UTC, Basile B. wrote: float.init is not equal to 0.0f. In D FP points values are initialized to nan (not a number). By the way for strings it works, it's like the array case I described in the

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread ArturG via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:29:52 UTC, Basile B. wrote: float.init is not equal to 0.0f. In D FP points values are initialized to nan (not a number). By the way for strings it works, it's like the array case I described in the first answer). yes i guess i tested all/most types and

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread Basile B. via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:25:03 UTC, arturg wrote: On Thursday, 26 May 2016 at 15:15:57 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:14:21 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:11:50 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote:

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread ArturG via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:25:26 UTC, ag0aep6g wrote: On 05/26/2016 04:03 PM, ArturG wrote: for example: if(any floatingpoint.init) will be true if(any char.init) also true if("") also true while others are false e.g. string s; if(s) will be false all others are also false or did i miss

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread ag0aep6g via Digitalmars-d-learn
On 05/26/2016 04:03 PM, ArturG wrote: for example: if(any floatingpoint.init) will be true if(any char.init) also true if("") also true while others are false e.g. string s; if(s) will be false all others are also false or did i miss any? What does it matter?

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread arturg via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:15:57 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:14:21 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:11:50 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote: [...] [...] - integral(*): if (i) <=> if (i > 0) I

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread Basile B. via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:14:21 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:11:50 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote: [...] [...] - integral(*): if (i) <=> if (i > 0) I obviously meant: - integral(*): if (i) <=> if (i <> 0) and

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread Basile B. via Digitalmars-d-learn
On Thursday, 26 May 2016 at 15:11:50 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote: [...] [...] - integral(*): if (i) <=> if (i > 0) I obviously meant: - integral(*): if (i) <=> if (i <> 0) and "<=>" stands for "equivalence"

Re: Why do some T.init evaluate to true while others to false?

2016-05-26 Thread Basile B. via Digitalmars-d-learn
On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote: for example: if(any floatingpoint.init) will be true if(any char.init) also true if("") also true while others are false e.g. string s; if(s) will be false all others are also false or did i miss any? It's a shortcut that works for