CS0564

[PGP]

This error has the following description - "Overloaded shift operator must
have the type of the first operand be the containing type, and the type of
the second operand must be int."

Could you please explain the need for this restriction? In fact, i want this
to be an insertion operator where i can use something like myclass << "c" <<
"d" << "e". Is there a better way to express this in C#?

 

[Jon Skeet [C# MVP]]

This error has the following description - "Overloaded shift operator must
have the type of the first operand be the containing type, and the type of
the second operand must be int."

Could you please explain the need for this restriction? In fact, i want this
to be an insertion operator

And that's the problem. It's not an insertion operator, it's a shift
operator. C++ abused this IMO by making it mean something completely
different in some situations.

where i can use something like myclass << "c" <<
"d" << "e". Is there a better way to express this in C#?

That really depends on the semantics involved. "+" is often
appropriate, or just use methods.

 

[PGP]

And that's the problem. It's not an insertion operator, it's a shift
operator. C++ abused this IMO by making it mean something completely
different in some situations.

I thought we called it "operator overloading" for a reason. I understand
that the shift
operator is only meant to shift and it can only take int params. What i dont
see is that there
is no way to enforce this all the way through ( I could override + and do -
in it still). So why stand in the way of
otherwise ease of expression?

 

[Jon Skeet [C# MVP]]

I thought we called it "operator overloading" for a reason.

Yes - because you overload the operators to work with different types.
In the case of shift, however, it doesn't make sense to shift with non-
integer values. Restricting shift to work with an integer second

I understand that the shift operator is only meant to shift and it
can only take int params. What i dont see is that there is no way to
enforce this all the way through ( I could override + and do - in it
still). So why stand in the way of otherwise ease of expression?

Because your ease of expression is other people's readability
nightmare. When I see << or >>, I think "shift". We can't stop people
from making "+" to subtraction, or "-" do division, but by restricting
the operand types we can at least discourage such things.

 

[Peter Duniho]

Yes - because you overload the operators to work with different types.
In the case of shift, however, it doesn't make sense to shift with non-
integer values. Restricting shift to work with an integer second
operand means that people can't make << and >> mean things other than
shift quite as easily.

I see his point though.

The + operator has been expanded to include not just arithmetic addition,
but concatenation (for example) of strings. There's not really any
mathematical equivalent to that which would justify the use of an addition
operator to represent that.

Likewise, if you describe the << and >> operators as "shift", well...that
word can mean a variety of things, and I can easily see it as meaning
something that is still easily understood as "shifting" but which allows a
non-integer magnitude for the shift. For example, scrolling or resizing a
bitmap.

The use of the shift operators in C++ for i/o always did bug me, and I'd
say that's a pretty clear departure from any intuitive idea of what a
"shift" would be. But that's not to say there aren't a wide variety of
other uses for a shift operator that *aren't* such a departure, and yet
could plausibly accept a non-integer operand.

The whole thing does seem a bit arbitrary to me.

Fortunately, operators are really just a luxury. Pretty much anything you
can do with an operator, you can just write a method to do instead, and
apply whatever types to the parameters you see fit. So it's not really a
big deal what the language designers decided with respect to arbitrarily
restricting the use of an operator. But it's still an arbitrary
restriction IMHO.

Pete

 

[Jon Skeet [C# MVP]]

I see his point though.

I do to some extent, but I'm

The + operator has been expanded to include not just arithmetic addition,
but concatenation (for example) of strings. There's not really any
mathematical equivalent to that which would justify the use of an addition
operator to represent that.

Not strictly mathematical - but the intuitive idea of adding two
strings together is to concatenate them, I'd say.

Likewise, if you describe the << and >> operators as "shift", well...that
word can mean a variety of things, and I can easily see it as meaning
something that is still easily understood as "shifting" but which allows a
non-integer magnitude for the shift. For example, scrolling or resizing a
bitmap.

That's true. Being able to translate a point by a vector would be
reasonable.
Not sure about resizing, but each to their own.

The use of the shift operators in C++ for i/o always did bug me, and I'd
say that's a pretty clear departure from any intuitive idea of what a
"shift" would be. But that's not to say there aren't a wide variety of
other uses for a shift operator that *aren't* such a departure, and yet
could plausibly accept a non-integer operand.

The whole thing does seem a bit arbitrary to me.

I suspect that if C++ hadn't abused the shift operator, the C# (or CLI
- I'm not sure where the restriction really comes from, off-hand)
designers wouldn't have restricted it in the way they did.

Fortunately, operators are really just a luxury. Pretty much anything you
can do with an operator, you can just write a method to do instead, and
apply whatever types to the parameters you see fit. So it's not really a
big deal what the language designers decided with respect to arbitrarily
restricting the use of an operator. But it's still an arbitrary
restriction IMHO.

That's a fair analysis, yes. Given the proposed use in this thread, I
think it was a reasonable one - from the C++ heritage, people would
almost certainly abuse the same operator in the same way if they were
allowed to.

(It's one of the things I don't like about Groovy, btw

Jon

 

[PGP]

Because your ease of expression is other people's readability
nightmare. When I see << or >>, I think "shift". We can't stop people
from making "+" to subtraction, or "-" do division, but by restricting
the operand types we can at least discourage such things.

I dont see the readability argument at all. Shift something into something
and
shift something out of something is quite readable to me. Quite intuitive
too,
look at the direction of the arrows. Counter-intuitive to call it shift
maybe though.

 

[PGP]

Pete,
Excellent points. Thanks.

The whole thing does seem a bit arbitrary to me.

Exactly. This defenitely looks like a restriction for the sake of
restriction.

 

[Peter Duniho]

[...]

I see his point though.

I do to some extent, but I'm

I think you got cut off there.

[...] There's not really any
mathematical equivalent to that which would justify the use of an
addition operator to represent that.

Not strictly mathematical - but the intuitive idea of adding two
strings together is to concatenate them, I'd say.

Well, that's my point. I agree that concatenation is a reasonably
intuitive use of the + operator. But following the same logic used to
restrict the shift operators, the + operator would be restricted to only
numeric values (for example).

[...]
I suspect that if C++ hadn't abused the shift operator, the C# (or CLI
- I'm not sure where the restriction really comes from, off-hand)
designers wouldn't have restricted it in the way they did.

Probably. Isn't that how it goes though? One bad apple ruins the party
for the rest of us.

Pete

 

[Jon Skeet [C# MVP]]

I dont see the readability argument at all. Shift something into
something and shift something out of something is quite readable to
me. Quite intuitive too, look at the direction of the arrows.
Counter-intuitive to call it shift maybe though.

But that's the thing - the operator *is* the shift operator. That's
what it's defined to be. Just because the arrows might look like they
could do something else as well as the specified meaning doesn't mean
it's a good idea.

 

[PGP]

But that's the thing - the operator *is* the shift operator. That's
what it's defined to be. Just because the arrows might look like they
could do something else as well as the specified meaning doesn't mean
it's a good idea.

The thing is that it's easy to say - that's how it is, use member functions
if
you need to get creative. But let me ask you this, would you trade the +
operator
on strings for String.Add("123") ?. Isnt there clarity when you write
a = a+b+c ? My point is, my container / stream class which could have used
<< operators the
same way now have to do stream.Insert(a).Insert(b).Insert(c).
All i know is that i am willing to live with the supposedly huge ambiguity
created by
stream << a << b << c. (well, then go live where you can do that.. right?

 

[Jon Skeet [C# MVP]]

The thing is that it's easy to say - that's how it is, use member functions
if you need to get creative. But let me ask you this, would you trade the +
operator on strings for String.Add("123") ?. Isnt there clarity when you write
a = a+b+c ?

Yes - but then adding two strings together makes sense. Shifting things
into streams doesn't, IMO.

My point is, my container / stream class which could have used
<< operators the same way now have to do stream.Insert(a).Insert(b).Insert(c).
All i know is that i am willing to live with the supposedly huge ambiguity
created by stream << a << b << c. (well, then go live where you can do
that.. right?

You may be willing to live with it - of course you'd find your own code
readable. What about other maintenance programmers who have to read
your code?

You're trying to impose a C++ convention in a non-C++ situation. Yes,
it'll be familiar to those who like C++ - but many others will be
confused.

 

[Bruce Wood]

I thought we called it "operator overloading" for a reason. I understand
that the shift
operator is only meant to shift and it can only take int params. What i dont
see is that there
is no way to enforce this all the way through ( I could override + and do -
in it still). So why stand in the way of
otherwise ease of expression?

Because that's a difference in design goals between C++ and C#: C++
gave you free rein to do pretty-much whatever you wanted, with the
caveat that you could produce truly screwy, confusing code if you did
it wrong. C++, IMHO, was aimed at the guru programmer.

C# is targeted more at the mainstream, and tries to stop you (where it
can) from doing things that will cause confusion.

Different design goals result in different languages.

 

[PGP]

You may be willing to live with it - of course you'd find your own code
readable. What about other maintenance programmers who have to read
your code?

Let's face it, is this really causing all that confusion? I wonder if there
is actually a mainstream
opinion against it.

 

[Jon Skeet [C# MVP]]

Let's face it, is this really causing all that confusion? I wonder if there
is actually a mainstream opinion against it.

I suspect that any poll measuring such opinion would be sharply divided
along lines of developers who had previously used C++ and those who
hadn'y.

 

[PGP]

C# is targeted more at the mainstream, and tries to stop you (where it
can) from doing things that will cause confusion.

How do you draw the conclusion that shift must have the second operand
as integer? + operator for example extends the concept of addition and
allows objects of any type to be the operands. If the design goal was
to extend the idea of shifting, how is is justified that you can only
shift by numbers?

 

[tjmadden1128]

How do you draw the conclusion that shift must have the second operand
as integer? + operator for example extends the concept of addition and
allows objects of any type to be the operands. If the design goal was
to extend the idea of shifting, how is is justified that you can only
shift by numbers?

I agree. Is the shift operation non-intuitive for strings or arrays?
"a" >> "bc" = "abc" and [1] >> [2, 3] = [1,2,3]
The first example would also be concatenation, yes. But if you really
wanted to get restrictive, shift operations are only obvious for base
2 numbers.

What operand would be obvious as an insertion operator?

 

[Jon Skeet [C# MVP]]

I agree. Is the shift operation non-intuitive for strings or arrays?

Absolutely! At least when using them as the RHS.

"a" >> "bc" = "abc" and [1] >> [2, 3] = [1,2,3]

Why? Those are *adding* things, not "shifting" them.

Now, the idea of shifting an array by a number *could* make sense:

[4, 5, 6] << 1 = [5, 6]
[4, 5, 6] >> 2 = [0, 0, 4, 5, 6]

That would make some sense to me. But shifting *by* another array? It
just isn't intuitive in the least for me.

The first example would also be concatenation, yes. But if you really
wanted to get restrictive, shift operations are only obvious for base
2 numbers.

Which is why it's not defined for double/float/decimal.

What operand would be obvious as an insertion operator?

Not sure what you're getting at here. How can an operand be an
operator? I don't think there has to be an operator for everything you
might want to do with a type. That's what methods are for.

Jon