?: as an lvalue

Richard Tobias wrote:
) In article <fsrdh6$ikl$1@registered.motzarella.org>,
) Richard  <devr_@gmail.com> wrote:
)>I think you have lost the track with all due respect. His original did
)>produce an lvalue but a value.
)
) I think the point was that * is an example of an operator that produces
) an lvalue, so it's not necessarily unreasonable for the ?: operator to.

Yes, but * _always_ produces lvalues.

If the ?: operator were to produce lvalues, it can only do so sometimes,
which makes it a lot more difficult to do so.

I think this argument has already been made crossthread, by the way.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> Richard wrote: 
>
> I'm not really arguing. The way I interpreted your responses, it
> seemed that when someone said that in C++ '?:' would return an lvalue
> in this case, you essentially made it clear that you find it unnatural
> and/or illogical (again, the way I interpreted your responses). I just
> want to know what is it exactly that you find unnatural and/or
> illogical.

Firstly I wasnt aware of any C++ talk.

Secondly, I find it unnatural because it is a special operator which,
well, does not return an lvalue. Sure, I'm only arguing for "what it
is". When someone claims "this makes perfect" sense and it does not make
any sense at all in the context of the language being discussed then I
think thats a fair response.

Bartc <bc@freeuk.com> wrote:
>
> Exactly why a?b:c can't appear like that on the left-hand-side of an
> assignment is a bit of a mystery; after all a, a.b, a->b, a[b] and so on can
> all appear on the lhs without the programmer having to insert explicit
> address-of operators.

Because b and c are two distinct objects that can have different types,
which makes the type of any resulting lvalue somewhat problematic.

-Larry Jones

Please tell me I'm adopted. -- Calvin

lawrence.jones@siemens.com writes:

> Bartc <bc@freeuk.com> wrote: 
>
> Because b and c are two distinct objects that can have different types,
> which makes the type of any resulting lvalue somewhat problematic.
>
> -Larry Jones

That should nail it ...

lawrence.jones@siemens.com wrote:
> ...
> Because b and c are two distinct objects that can have different types,
> which makes the type of any resulting lvalue somewhat problematic.
> ...

Yes, it does. But when the second and the third operand have different
(more precisely: non-compatible) types, there are quite a few things
related to '?:' that are "problematic". The "lvalue" issue is just one
of them. I we approach all of these issues with the same degree of
pessimism, then we should probably prohibit '?:' operator entirely.

A more concrete example: in C language the '?:' operator can be applied
to structures and unions. Of course, it is required that the second and
the third operand have the same type (more precisely: compatible types).
Needless to say, even though the result is not an lvalue, the idea to
allow '?:' with structures immediately runs into the very same
type-compatibility issues you are referring to. Still, it is perfectly
legal in C to apply '?:' to structures. This illustrates the fact that
in the process of language evolution the type-compatibility issue in
'?:' has not been seen as a reason to discard a feature.

--
Best regards,
Andrey Tarasevich

Richard wrote: 
> That should nail it ...

No, that completely misses it. For example, what will happen if you try
to compile this

double* d;
int* i;

1 < 0 ? d : i;

Here's another example

struct A { int i; } a;
struct B { int i; } b;

1 < 0 ? a : b;

I'll answer it for you: in both cases the code is invalid. It won't
compile. Why? Because the existing type-compatibility requirements
imposed on the second and third parameter of '?:' have been violated.
Note, that this is normal C '?:', which returns a non-lvalue. Did that
little "non-lvalue" detail somehow help it to compile in the above
example? No, it didn't.

What it illustrates is that the type-compatibility requirements are
_already_ in the language. They are already there and there's no way
around them. The fact that '?:' returns a non-lvalue in C doesn't really
make things easier. And making '?:' return an lvalue wouldn't really
make things harder.

(And, once again, this is a purely academic argument for me. I'm not
trying to campaign for lvalue-returning '?:')

--
Best regards,
Andrey Tarasevich

Richard <devr_@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
>
> Huh? I must be missing something here or I will be first to
> apologise.

I just wanted you to say why it seemed so obvious to you that C
outlaws the construct.  I thought that maybe you knew a good reason
why.  Lots of languages allow such things.

> We already know that
>
> *(c?x:y)=v;
>
> is ok where x and y are pointers.
>
> But (c?x:y)=v;
>
> I dont really know what to say.

OK, that's fine.  Your degree of certainty (that the prohibition was
not mysterious) suggested you might have something to say about it.

It is another areas in which C and C++ have diverged.  I thought there
was a desire that differences be minimised in what might loosely be
called the "common areas" unless there is a compelling reason to keep
C different.  I thought maybe you knew that reason.

--
Ben.

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> Richard wrote: 
>
> No, that completely misses it. For example, what will happen if you
> try to compile this
>
>   double* d;
>   int* i;
>
>   1 < 0 ? d : i;
>
> Here's another example
>
>   struct A { int i; } a;
>   struct B { int i; } b;
>
>   1 < 0 ? a : b;
>
> I'll answer it for you: in both cases the code is invalid. It won't
> compile. Why? Because the existing type-compatibility requirements
> imposed on the second and third parameter of '?:' have been
> violated. Note, that this is normal C '?:', which returns a

Exactly.

Flash Gordon wrote:
> Bartc wrote, On 31/03/08 18:45: 
 
>
> You can't do 3 = x

That's true. But when a is a variable, it can appear on the lhs without any
special syntax.
 
>
> You can't do 5.b or a.5

Then it won't work on the rhs either.

> 
>
> You can't do 5->b or b->5

Nor this.

> 
>
> Unless b is a pointer or array name you can't do 5[b]
> 
>
> You can do a?1:2

On rhs yes. On lhs? I don't think so.
 
>
> I think you are wrong. Look at the fact that all of the other
> operators you mention *require* at least one of the operands to be an
> object but neither + nor ?: require and operand to be an object. Then
> you should see why it is natural for a?b:c = x to be wrong.

That's true. And probably the reason it was disallowed in C.

But when both selections of ?: /are/ legal lvalues there doesn't seem to be
a particular problem. After all the lhs of an assigment must be an lvalue,
so why not insist on both values of an ?: on the lhs being lvalues?

For example if someone tries to write:

a ? b : c+d = x;

then clearly there's an error. But that's no different from the equally
incorrect:

if (a)
b = x;
else
c+d = x;

I suppose I should put my cards on the table here: I have written compilers
for C-class languages where such an expression on lhs of an assignment is
valid (in fact anything can appear on the lhs provided it yields an lvalue).
So the following nested ?: operation is possible:

(a | b | (c | d | e)) := 100        /* syntax is (a|b|c)  not a?b:c */

This assigns 100 to either b, d or e depending on a and c. Not that such a
construct, even the simpler a?b:c form, is used that often! :-)

But it's clearly controversial in C.

--
Bart

Richard <devr_@gmail.com> writes:

> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> 
>
> Exactly.

That is too terse.  It seems unlikely that you agree with Andrey
Tarasevitch since he is explaining why your "that should nail it"
comment was a bit premature.

If you disagree, you would need to have commented on the bit you
clipped:

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
| What it illustrates is that the type-compatibility requirements are
| _already_ in the language. They are already there and there's no way
| around them. The fact that '?:' returns a non-lvalue in C doesn't
| really make things easier. And making '?:' return an lvalue wouldn't
| really make things harder.

Type-checking (c ? a : b) = v; is not obviously any harder than
type-checking v = (c ? a : b);.

--
Ben.