www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - that is bug?

reply sdvcn <sdvcn 126.com> writes:
	string stt = "none";
	true?writeln("AA"):writeln("BB");   ///Out:AA
         true?stt="AA":stt="BB";    <<<<-----///Out:BB
	writeln(stt);
Apr 07 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, April 07, 2018 09:07:48 sdvcn via Digitalmars-d wrote:
   string stt = "none";
   true?writeln("AA"):writeln("BB");   ///Out:AA
          true?stt="AA":stt="BB";    <<<<-----///Out:BB
   writeln(stt);
Assignment takes precendence over the ternary operator. So, no, I don't think that it is. Putting parens around the assignment expressions makes it print AA. As it stands, it evaluates both assignment expressions before evaluating the ternary operator. In general, I'd advise against using expressions with side effects in the branches of a ternary operator, since it's easy to end up with a result that doesn't do what you think it does (or which readers of your code will misinterpret) - or you can just always use parens, but the folks who do that generally end up using parens when they're completely unnecessary, which IMHO makes the code uglier and harder to read. Either way, if you're doing assignment, it generally makes more sense to put it outside the ternary operator. e.g. stt = condition ? "AA" : "BB"; Also FYI, questions should generally be asked in the D.Learn newsgroup/forum instead of the main newsgroup/forum, which is for more general discussions on D and how to improve it. - Jonathan M Davis
Apr 07 2018
parent reply kdevel <kdevel vogtner.de> writes:
On Saturday, 7 April 2018 at 09:56:43 UTC, Jonathan M Davis wrote:
          true?stt="AA":stt="BB";    <<<<-----///Out:BB
[...]
 Assignment takes precendence over the ternary operator.
That's not true. Not in D and not in C/C++ https://wiki.dlang.org/Operator_precedence http://en.cppreference.com/w/c/language/operator_precedence#cite_note-2
 So, no, I don't think that it is. Putting parens around the 
 assignment expressions makes it print AA.
It should not matter if there are parens around the assignment.
 As it stands, it evaluates both assignment expressions before 
 evaluating the ternary operator.
That is not true in C/C++, let me quote from a C standard (draft), § 6.1.5 conditional operator: [this is about <first op> ? <second op> : <third op>] "Semantics The first operand is evaluated; there is a sequence point between its evaluation and the evaluation of the second or third operand (whichever is evaluated). The second operand is evaluated only if the first compares unequal to 0; the third operand is evaluated only if the first compares equal to 0; the result is the value of the second or third operand (whichever is evaluated), converted to the type described below.110)" According to https://dlang.org/spec/expression.html#conditional_expressions the same shall be valid for D. Hence when true ? s = A : s = B; or true ? (s = A) : (s = B); does not yield A for s it's a bug.
Apr 07 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, April 07, 2018 14:28:05 kdevel via Digitalmars-d wrote:
 On Saturday, 7 April 2018 at 09:56:43 UTC, Jonathan M Davis wrote:
          true?stt="AA":stt="BB";    <<<<-----///Out:BB
[...]
 Assignment takes precendence over the ternary operator.
That's not true. Not in D and not in C/C++ https://wiki.dlang.org/Operator_precedence http://en.cppreference.com/w/c/language/operator_precedence#cite_note-2
 So, no, I don't think that it is. Putting parens around the
 assignment expressions makes it print AA.
It should not matter if there are parens around the assignment.
 As it stands, it evaluates both assignment expressions before
 evaluating the ternary operator.
That is not true in C/C++, let me quote from a C standard (draft), § 6.1.5 conditional operator: [this is about <first op> ? <second op> : <third op>] "Semantics The first operand is evaluated; there is a sequence point between its evaluation and the evaluation of the second or third operand (whichever is evaluated). The second operand is evaluated only if the first compares unequal to 0; the third operand is evaluated only if the first compares equal to 0; the result is the value of the second or third operand (whichever is evaluated), converted to the type described below.110)" According to https://dlang.org/spec/expression.html#conditional_expressions the same shall be valid for D. Hence when true ? s = A : s = B; or true ? (s = A) : (s = B); does not yield A for s it's a bug.
You're right. It's what I get for responding too early in the morning. - Jonathan M Davis
Apr 07 2018
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 7 April 2018 at 14:28:05 UTC, kdevel wrote:
 On Saturday, 7 April 2018 at 09:56:43 UTC, Jonathan M Davis 
 wrote:
          true?stt="AA":stt="BB";    <<<<-----///Out:BB
[...]
 Assignment takes precendence over the ternary operator.
That's not true. Not in D and not in C/C++
The odd man out is C++ [1], assignment has higher precedence because of right to left evaluation. Do not mix it with C please. All other C derived languages have indeed higher precedence for [1]: http://en.cppreference.com/w/cpp/language/operator_precedence [2]: http://en.cppreference.com/w/c/language/operator_precedence [3]: https://introcs.cs.princeton.edu/java/11precedence/ [4]: https://www.tutorialspoint.com/csharp/csharp_operators_precedence.htm [5]: https://wiki.dlang.org/Operator_precedence
 https://wiki.dlang.org/Operator_precedence
 http://en.cppreference.com/w/c/language/operator_precedence#cite_note-2

 So, no, I don't think that it is. Putting parens around the 
 assignment expressions makes it print AA.
It should not matter if there are parens around the assignment.
 As it stands, it evaluates both assignment expressions before 
 evaluating the ternary operator.
That is not true in C/C++, let me quote from a C standard (draft), § 6.1.5 conditional operator:
Stop mixing C with C++ they are really 2 very different beasts (one is a programming language, the other is Cthulu :-) <snip>
Apr 07 2018
parent reply kdevel <kdevel vogtner.de> writes:
On Saturday, 7 April 2018 at 16:52:00 UTC, Patrick Schluter wrote:
[...]
 The odd man out is C++ [1], assignment has higher precedence 
 because of right to left evaluation.
Your reference [1] is not even a witness to your claim. The precedence table says that the "Ternary conditional" has the *same* precedence as the "Direct Assigment", namely "16". You may find an in-depth discussion of the C++ case in https://stackoverflow.com/questions/7499400/ternary-conditional-and-assignment-operator-precedence
Apr 07 2018
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 7 April 2018 at 20:57:23 UTC, kdevel wrote:
 On Saturday, 7 April 2018 at 16:52:00 UTC, Patrick Schluter 
 wrote:
 [...]
 The odd man out is C++ [1], assignment has higher precedence 
 because of right to left evaluation.
Your reference [1] is not even a witness to your claim. The precedence table says that the "Ternary conditional" has the *same* precedence as the "Direct Assigment", namely "16". You may find an in-depth discussion of the C++ case in https://stackoverflow.com/questions/7499400/ternary-conditional-and-assignment-operator-precedence
My formulation was ambiguous, it is the same precedence as the link says. The link also says that's it's right to left evaluation. This means that for expression: a ? b = c : d = e; right to left evaluation will make the = e assignment higher priority than the b = c assignment or the ternary even if they have the same priority level. The operative word was the right to left but granted I could have formulated it better.
Apr 08 2018
parent reply kdevel <kdevel vogtner.de> writes:
On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter wrote:
 You may find an in-depth discussion of the C++ case in

 https://stackoverflow.com/questions/7499400/ternary-conditional-and-assignment-operator-precedence
My formulation was ambiguous, it is the same precedence as the link says. The link also says that's it's right to left evaluation. This means that for expression: a ? b = c : d = e; right to left evaluation will make the = e assignment higher priority than the b = c assignment or the ternary even if they have the same priority level.
To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an l-value: ccondo1.c --- int main () { int a, b; 1 ? a = 1 : b = 2; return 0; } --- $ cc ccondo1.c ccondo1.c: In function 'main': ccondo1.c:4: error: lvalue required as left operand of assignment Other languages: ---------------- - go: has no ternary conditional - Java: Same as in C, example does not compile due to missing l-value. - JS: Like C++ (!). https://www.ecma-international.org/ecma-262/6.0/#sec-conditional-operator "The grammar for a ConditionalExpression in ECMAScript is slightly different from that in C and Java, which each allow the second subexpression to be an Expression but restrict the third expression to be a ConditionalExpression. The motivation for this difference in ECMAScript is to allow an assignment expression to be governed by either arm of a conditional and to eliminate the confusing and fairly useless case of a comma expression as the centre expression."
Apr 08 2018
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 8 April 2018 at 10:03:33 UTC, kdevel wrote:
 On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter wrote:
 You may find an in-depth discussion of the C++ case in

 https://stackoverflow.com/questions/7499400/ternary-conditional-and-assignment-operator-precedence
My formulation was ambiguous, it is the same precedence as the link says. The link also says that's it's right to left evaluation. This means that for expression: a ? b = c : d = e; right to left evaluation will make the = e assignment higher priority than the b = c assignment or the ternary even if they have the same priority level.
To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an l-value:
Exactly Now, the only thing is to clearly define what it is in D, as apparently it is neither the C++ nor the C behaviour. The old precedence table on the D wiki seems to say it is like C, but the example of that thread seems to show it's not.
Apr 08 2018
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 8 April 2018 at 16:47:59 UTC, Patrick Schluter wrote:
 On Sunday, 8 April 2018 at 10:03:33 UTC, kdevel wrote:
 On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter 
 wrote:
 [...]
To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an l-value:
Exactly Now, the only thing is to clearly define what it is in D, as apparently it is neither the C++ nor the C behaviour. The old precedence table on the D wiki seems to say it is like C, but the example of that thread seems to show it's not.
To follow up. What's surprizing for a C guy like me is that D accepts without problems (a=1)=2; i.e. that (a=1) is a lvalue.
Apr 08 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, April 08, 2018 16:59:35 Patrick Schluter via Digitalmars-d wrote:
 On Sunday, 8 April 2018 at 16:47:59 UTC, Patrick Schluter wrote:
 On Sunday, 8 April 2018 at 10:03:33 UTC, kdevel wrote:
 On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter

 wrote:
 [...]
To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an
 l-value:
Exactly Now, the only thing is to clearly define what it is in D, as apparently it is neither the C++ nor the C behaviour. The old precedence table on the D wiki seems to say it is like C, but the example of that thread seems to show it's not.
To follow up. What's surprizing for a C guy like me is that D accepts without problems (a=1)=2; i.e. that (a=1) is a lvalue.
I would fully expect it to be assignable, but I'm a C++ guy, not a C guy. I just tried it with both C, C++, and D though, and it does indeed fail to compile with C while it compiles perfectly fine with C++ and D. - Jonathan M Davis
Apr 08 2018
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/08/2018 09:59 AM, Patrick Schluter wrote:
 On Sunday, 8 April 2018 at 16:47:59 UTC, Patrick Schluter wrote:
 On Sunday, 8 April 2018 at 10:03:33 UTC, kdevel wrote:
 On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter wrote:
 [...]
To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an l-value:
Exactly Now, the only thing is to clearly define what it is in D, as apparently it is neither the C++ nor the C behaviour. The old precedence table on the D wiki seems to say it is like C, but the example of that thread seems to show it's not.
To follow up. What's surprizing for a C guy like me is that D accepts without problems    (a=1)=2; i.e. that (a=1) is a lvalue.
I don't have any problem with that part either. The following makes sense to me. I may have even used it in the past (likely in C++): (cond ? a : b) = foo; Ali
Apr 08 2018
parent reply MattCoder <no spam.com> writes:
On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:
 ...
 I don't have any problem with that part either. The following 
 makes sense to me. I may have even used it in the past (likely 
 in C++):

     (cond ? a : b) = foo;
 ...
For me as a C programmer this is different. What happens in this case? It will be assign foo to either a or b? Matt.
Apr 09 2018
next sibling parent Uknown <sireeshkodali1 gmail.com> writes:
On Monday, 9 April 2018 at 14:28:54 UTC, MattCoder wrote:
 On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:
 ...
 I don't have any problem with that part either. The following 
 makes sense to me. I may have even used it in the past (likely 
 in C++):

     (cond ? a : b) = foo;
 ...
For me as a C programmer this is different. What happens in this case? It will be assign foo to either a or b? Matt.
Depending on the condition, foo will be assigned to either a or b
Apr 09 2018
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 9 April 2018 at 14:28:54 UTC, MattCoder wrote:
 On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:
 ...
 I don't have any problem with that part either. The following 
 makes sense to me. I may have even used it in the past (likely 
 in C++):

     (cond ? a : b) = foo;
 ...
For me as a C programmer this is different. What happens in this case? It will be assign foo to either a or b?
Except that it is not allowed in standard C. gcc says error: lvalue required as left operand of assignment to that.
Apr 09 2018
parent MattCoder <no spam.com> writes:
On Monday, 9 April 2018 at 15:20:58 UTC, Patrick Schluter wrote:
 ...
 For me as a C programmer this is different. What happens in 
 this case? It will be assign foo to either a or b?
Except that it is not allowed in standard C. gcc says ...
Yes I know, that's why I said, it's different... ("From where I came"). Matt.
Apr 09 2018
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:
         true?stt="AA":stt="BB";    <<<<-----///Out:BB
It's an UB. Not a bug.
Apr 07 2018
next sibling parent reply meppl <mephisto nordhoff-online.de> writes:
On Saturday, 7 April 2018 at 10:25:19 UTC, bauss wrote:
 On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:
         true?stt="AA":stt="BB";    <<<<-----///Out:BB
It's an UB. Not a bug.
I want `condition ? expr1 : expr2` to behave like: ----- auto qc( alias condition, string expr1, string expr2)() { if( condition) { return mixin( expr1); } else { return mixin( expr2); } } -----
Apr 07 2018
parent Seb <seb wilzba.ch> writes:
On Saturday, 7 April 2018 at 11:19:44 UTC, meppl wrote:
 On Saturday, 7 April 2018 at 10:25:19 UTC, bauss wrote:
 On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:
         true?stt="AA":stt="BB";    <<<<-----///Out:BB
It's an UB. Not a bug.
I want `condition ? expr1 : expr2` to behave like: ----- auto qc( alias condition, string expr1, string expr2)() { if( condition) { return mixin( expr1); } else { return mixin( expr2); } } -----
You can do so today with lazy: --- import std.stdio; auto qc(E1, E2)(bool condition, lazy E1 expr1, lazy E2 expr2) { if (condition) { return expr1; } else { return expr2; } } void main() { qc(true, "A".writeln, "B".writeln); string s; qc(true, s = "A", s = "B"); s.writeln; } --- https://run.dlang.io/is/ymZBht https://dlang.org/articles/lazy-evaluation.html
Apr 07 2018
prev sibling parent reply kdevel <kdevel vogtner.de> writes:
On Saturday, 7 April 2018 at 10:25:19 UTC, bauss wrote:
 On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:
         true?stt="AA":stt="BB";    <<<<-----///Out:BB
It's an UB. Not a bug.
Why UB? stt is only modified once.
Apr 07 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, April 07, 2018 14:29:15 kdevel via Digitalmars-d wrote:
 On Saturday, 7 April 2018 at 10:25:19 UTC, bauss wrote:
 On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:
         true?stt="AA":stt="BB";    <<<<-----///Out:BB
It's an UB. Not a bug.
Why UB? stt is only modified once.
It's modified twice. This import std.stdio; struct S { S opAssign(string str) { writeln(str); return S.init; } } void main() { S stt; true ? stt = "AA" : stt = "BB"; } prints AA BB whereas this import std.stdio; struct S { S opAssign(string str) { writeln(str); return S.init; } } void main() { S stt; true ? (stt = "AA") : (stt = "BB"); } prints AA However, similar code in C++ #include <stdio.h> class C { public: C& operator=(int i) { printf("%d\n", i); return *this; } }; int main() { C c; true ? c = 42 : c = 29; return 0; } prints the first value only, which would imply (though not guarantee) that the D behavior is a bug. - Jonathan M Davis
Apr 07 2018
parent kdevel <kdevel vogtner.de> writes:
On Saturday, 7 April 2018 at 14:43:53 UTC, Jonathan M Davis wrote:
 On Saturday, April 07, 2018 14:29:15 kdevel via Digitalmars-d 
 wrote:
 On Saturday, 7 April 2018 at 10:25:19 UTC, bauss wrote:
 On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:
         true?stt="AA":stt="BB";    <<<<-----///Out:BB
It's an UB. Not a bug.
Why UB? stt is only modified once.
It's modified twice.
So we have diffrent behavior of D wrt to C.
 [...] which would imply (though not guarantee) that the D 
 behavior is a bug.
After rereading https://dlang.org/spec/expression.html#conditional_expressions carefully I found that Unlike § 6.1.5 of the C standard the "only" is missing in the D docs.
Apr 07 2018
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/07/2018 02:07 AM, sdvcn wrote:
      string stt = "none";
      true?writeln("AA"):writeln("BB");   ///Out:AA
          true?stt="AA":stt="BB";    <<<<-----///Out:BB
      writeln(stt);
It is a bug because the behavior does not match the spec: https://issues.dlang.org/show_bug.cgi?id=18743 Ali
Apr 07 2018
parent reply Ali <fakeemail example.com> writes:
On Saturday, 7 April 2018 at 15:26:56 UTC, Ali Çehreli wrote:
 On 04/07/2018 02:07 AM, sdvcn wrote:
      string stt = "none";
      true?writeln("AA"):writeln("BB");   ///Out:AA
          true?stt="AA":stt="BB";    <<<<-----///Out:BB
      writeln(stt);
It is a bug because the behavior does not match the spec: https://issues.dlang.org/show_bug.cgi?id=18743 Ali
Hi Ali C I think it also a bug because the ternary seem to be returning the second part try string stt = "none"; string b = ""; true?writeln("AA"):writeln("BB"); ///Out:AA b = (true ? stt="AA":stt="BB"); ///Out:BB writeln(stt); writeln(b); ///Out:BB
Apr 07 2018
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/07/2018 10:53 AM, Ali wrote:
 On Saturday, 7 April 2018 at 15:26:56 UTC, Ali Çehreli wrote:
 On 04/07/2018 02:07 AM, sdvcn wrote:
      string stt = "none";
      true?writeln("AA"):writeln("BB");   ///Out:AA
          true?stt="AA":stt="BB";    <<<<-----///Out:BB
      writeln(stt);
It is a bug because the behavior does not match the spec: https://issues.dlang.org/show_bug.cgi?id=18743 Ali
Hi Ali C I think it also a bug because the ternary seem to be returning the second part
Maybe... but the following is not a good test for that because the return value of the assignment operator would always be stt regardless of which expression is evaluated.
 try

      string stt = "none";
      string b = "";
      true?writeln("AA"):writeln("BB");   ///Out:AA
      b = (true ? stt="AA":stt="BB");    ///Out:BB
      writeln(stt);
      writeln(b); ///Out:BB
I tried something else and noticed that it doesn't actually evaluate the third expression because b is never changed: import std.stdio; void main() { int a; int b; int * c = &(true ? a = 1 : b = 2); writefln("a:%s %s", a, &a); writefln("b:%s %s", b, &b); writefln("c: %s", c); } Output: a:2 7FFDBBF57DB0 <-- Got the value of the third expression (BAD) b:0 7FFDBBF57DB4 <-- Not changed (good) c: 7FFDBBF57DB0 <-- Address of a (good) So, the expression correctly decides to affect and returns 'a' but uses the wrong value to assign. Ali
Apr 07 2018
parent reply Ali <fakeemail example.com> writes:
On Saturday, 7 April 2018 at 18:52:56 UTC, Ali Çehreli wrote:
 On 04/07/2018 10:53 AM, Ali wrote:
 On Saturday, 7 April 2018 at 15:26:56 UTC, Ali Çehreli wrote:
 On 04/07/2018 02:07 AM, sdvcn wrote:
      string stt = "none";
      true?writeln("AA"):writeln("BB");   ///Out:AA
          true?stt="AA":stt="BB";    <<<<-----///Out:BB
      writeln(stt);
It is a bug because the behavior does not match the spec: https://issues.dlang.org/show_bug.cgi?id=18743 Ali
Hi Ali C I think it also a bug because the ternary seem to be
returning the
 second part
Maybe... but the following is not a good test for that because the return value of the assignment operator would always be stt regardless of which expression is evaluated.
 try

      string stt = "none";
      string b = "";
      true?writeln("AA"):writeln("BB");   ///Out:AA
      b = (true ? stt="AA":stt="BB");    ///Out:BB
      writeln(stt);
      writeln(b); ///Out:BB
I tried something else and noticed that it doesn't actually evaluate the third expression because b is never changed: import std.stdio; void main() { int a; int b; int * c = &(true ? a = 1 : b = 2); writefln("a:%s %s", a, &a); writefln("b:%s %s", b, &b); writefln("c: %s", c); } Output: a:2 7FFDBBF57DB0 <-- Got the value of the third expression (BAD) b:0 7FFDBBF57DB4 <-- Not changed (good) c: 7FFDBBF57DB0 <-- Address of a (good) So, the expression correctly decides to affect and returns 'a' but uses the wrong value to assign. Ali
this kinda explains what happens to me try string stt = "none"; string b = ""; true?writeln("AA"):writeln("BB"); b = (true ? stt="AA": stt )="BB"; writeln(stt); writeln(b); output AA BB BB now try string stt = "none"; string b = ""; true?writeln("AA"):writeln("BB"); ///Out:AA (b = (true ? stt="AA": stt ))="BB"; ///Out:BB writeln(stt); writeln(b); output AA AA BB so it seems that since b = (true ? stt="AA": stt )="BB"; and b = true ? stt="AA": stt ="BB"; are equivalent that that the ternary operator return stt (after assigning it "AA") then assign "BB" to it
Apr 07 2018
parent reply kdevel <kdevel vogtner.de> writes:
On Saturday, 7 April 2018 at 19:44:35 UTC, Ali wrote:
 so it seems
 that since
     b = (true ? stt="AA": stt )="BB";
 and
     b = true ? stt="AA": stt ="BB";

 are equivalent
 that

 that the ternary operator return stt (after assigning it "AA") 
 then assign "BB" to it
Can the ternary conditional even be used to assign objects of the wrong type? dcondo.d --- import std.stdio; class A { int a; this (int i) { a = i; } } class C { int c; this (int i) { c = i; } } void dump (A a, A b, C c, C d) { a.writeln; b.writeln; c.writeln; d.writeln; a.a.writeln; b.a.writeln; c.c.writeln; d.c.writeln; } void main () { A a = new A (1), b = new A (2); C c = new C (3), d = new C (4); dump (a, b, c, d); true ? a = b : c = d; // a = c; // Error: cannot implicitly convert expression // c = a; // Error: cannot implicitly convert expression dump (a, b, c, d); } --- Output: dcondo.A dcondo.A dcondo.C dcondo.C 1 2 3 4 dcondo.C dcondo.A dcondo.C dcondo.C 4 2 3 4
Apr 07 2018
parent David Nadlinger <code klickverbot.at> writes:
On Saturday, 7 April 2018 at 21:22:07 UTC, kdevel wrote:
 Can the ternary conditional even be used to assign objects of 
 the wrong type?
 […]
Congratulations, I'm pretty sure you found an actual bug, even though it doesn't have anything to do with the conditional operator per se: https://issues.dlang.org/show_bug.cgi?id=18744 — David
Apr 07 2018
prev sibling parent David Nadlinger <code klickverbot.at> writes:
On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:
         true?stt="AA":stt="BB";    <<<<-----///Out:BB
 	writeln(stt);
As I just pointed out in Ali's bug report [1], this is correct, as true ? stt = "AA" : stt = "BB" means (true ? (stt = "AA") : stt) = "BB", in accordance to D's grammar [2]: AssignExpression: ConditionalExpression ConditionalExpression = AssignExpression […] We should probably require explicit parentheses here. Relying on this behaviour is just asking for trouble anyway, as evidenced by the amount of confusion in this thread. — David [1] https://issues.dlang.org/show_bug.cgi?id=18743 [2] https://dlang.org/spec/expression.html#assign_expressions
Apr 07 2018