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