foreach considered dangerous?

[cody]

foreach does implicitly cast every object in the collection to the specified
taget type without warning.
Without generics this behaviour had the advantage of less typing for us
since casting was neccessary in nearly every collection. But with generics I
consider this feature of foreach as dangerous. Casting is now almost always
unwanted.

interface IFoo{}
class Foo:IFoo{}
class FooBar:IFoo{}

IFoo[] fooarray = {new Foo()} ;

foreach (FooBar in fooarray) // oops InvalidCastExce ption
{
}

My proposal is now that foreach should in future emit a compiler warning if
implicit cast would occur.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[J.Marsch]

Cody:

I'm not sure that I follow your argument, but I'd like to understand it
better. The code example that you created would be invalid with or without
generics. I only see an explicit cast in the code (technically, it's
probably from object to FooBar, because the enumerator probably returns
object)
"cody" <no************ ****@gmx.net> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

foreach does implicitly cast every object in the collection to the specified taget type without warning.
Without generics this behaviour had the advantage of less typing for us
since casting was neccessary in nearly every collection. But with generics I consider this feature of foreach as dangerous. Casting is now almost always unwanted.

interface IFoo{}
class Foo:IFoo{}
class FooBar:IFoo{}

IFoo[] fooarray = {new Foo()} ;

foreach (FooBar in fooarray) // oops InvalidCastExce ption
{
}

My proposal is now that foreach should in future emit a compiler warning if implicit cast would occur.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[cody]

> I'm not sure that I follow your argument, but I'd like to understand it

better. The code example that you created would be invalid with or without generics. I only see an explicit cast in the code (technically, it's
probably from object to FooBar, because the enumerator probably returns
object)

Please reread my posting. there is an implicit cast from Foo to Foobar with
will cause an exception.

But see how dangerous foreach is: even if pointed to the problem people do
not see the invalid cast :)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[William Ryan eMVP]

J.

There's not a variable there, but this compiles and blows up
IFoo[] fooarray = {new Foo()} ;
foreach (FooBar f in fooarray) // oops InvalidCastExce ption

{
}

"J.Marsch" <je****@ctcdeve loper.com> wrote in message
news:OS******** ******@tk2msftn gp13.phx.gbl...

Cody:

I'm not sure that I follow your argument, but I'd like to understand it
better. The code example that you created would be invalid with or without generics. I only see an explicit cast in the code (technically, it's
probably from object to FooBar, because the enumerator probably returns
object)
"cody" <no************ ****@gmx.net> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

foreach does implicitly cast every object in the collection to the specified

taget type without warning.
Without generics this behaviour had the advantage of less typing for us
since casting was neccessary in nearly every collection. But with

generics I

consider this feature of foreach as dangerous. Casting is now almost

always

unwanted.

interface IFoo{}
class Foo:IFoo{}
class FooBar:IFoo{}

IFoo[] fooarray = {new Foo()} ;

foreach (FooBar in fooarray) // oops InvalidCastExce ption
{
}

My proposal is now that foreach should in future emit a compiler warning

if

implicit cast would occur.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[cody]

> There's not a variable there, but this compiles and blows up

IFoo[] fooarray = {new Foo()} ;
foreach (FooBar f in fooarray) // oops InvalidCastExce ption

{
}

Sorry I forgot :)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Daniel O'Connell [C# MVP]]

"cody" <no************ ****@gmx.net> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

foreach does implicitly cast every object in the collection to the
specified
taget type without warning.
Without generics this behaviour had the advantage of less typing for us
since casting was neccessary in nearly every collection. But with generics
I
consider this feature of foreach as dangerous. Casting is now almost
always
unwanted.

interface IFoo{}
class Foo:IFoo{}
class FooBar:IFoo{}

IFoo[] fooarray = {new Foo()} ;

foreach (FooBar in fooarray) // oops InvalidCastExce ption
{
}

My proposal is now that foreach should in future emit a compiler warning
if
implicit cast would occur.
The problem is that, without generics, you don't have a choice. And, sorry
to say it, assuming that everything will be generic is short sighted. You
will have to deal with collections typed as object for a long time to come.
foreach isn't dangerous in itself, its the developers fault if anything
fails, especially consdiering you defined the type and should be aware that
means a cast. If you have a collection that isn't strongly typed and you are
concerned it may hold incorrect data, you should be using for and as.

Having said that, the compiler should catch you if you use a type that an
IEnumerable<T> cannot cast or convert to. Which, frankly, is the desired
behaviour. Just throwing a warning if an implicit cast *may* happen on a
enumerator typed object is silly when the compiler can tell you that your
generic enumerator *cannot* perform the cast you want when the type is
FooBar but can't tell you that your cast on object will.

There is no reason to break existing behavior here, and a warning is
certainly not warranted. An error is when the type you request doesn't match
T of any IEnumerable<T> that is available, but thats a different matter
entirely.
--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[William Ryan eMVP]

Cody, it's a tiny oversight when bringing up such a good point. It really
didn't dawn on me before, but I agree totally, this is potentially quite
ugly problem.
"cody" <pl************ *************@g mx.de> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

There's not a variable there, but this compiles and blows up
IFoo[] fooarray = {new Foo()} ;
foreach (FooBar f in fooarray) // oops InvalidCastExce ption

{
}

Sorry I forgot :)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[cody]

> > foreach does implicitly cast every object in the collection to the

specified
taget type without warning.
Without generics this behaviour had the advantage of less typing for us
since casting was neccessary in nearly every collection. But with generics I
consider this feature of foreach as dangerous. Casting is now almost
always
unwanted.

interface IFoo{}
class Foo:IFoo{}
class FooBar:IFoo{}

IFoo[] fooarray = {new Foo()} ;

foreach (FooBar in fooarray) // oops InvalidCastExce ption
{
}

My proposal is now that foreach should in future emit a compiler warning
if
implicit cast would occur.
The problem is that, without generics, you don't have a choice. And, sorry
to say it, assuming that everything will be generic is short sighted.

Tell me one reason why to use collections containing objects.
This should only be used very very rarely and with lots ofconsideration
done.
You
will have to deal with collections typed as object for a long time to come. foreach isn't dangerous in itself, its the developers fault if anything
fails, especially consdiering you defined the type and should be aware that means a cast. If you have a collection that isn't strongly typed and you are concerned it may hold incorrect data, you should be using for and as.
Strictly speaking, there is no such thing like "strongly typed". If a have a
conventional list, it can contain object and all of its descendants.
If I have a list<IFoo> it can contain IFoo and *all* of its implementing
classes.

Maybe we have to invent a new feature will really allows "very strongly
typed" collections, so that exactly one certain type is allowed, but this
cannot be caught by the compiler.
Having said that, the compiler should catch you if you use a type that an
IEnumerable<T> cannot cast or convert to.
As I said the compiler won't complain it an implicit cast from baseclass to
descentant will take place which *may* be valid, or may not.
Which, frankly, is the desired behaviour.
I have to disagree.
Just throwing a warning if an implicit cast *may* happen on a
enumerator typed object is silly when the compiler can tell you that your
generic enumerator *cannot* perform the cast you want when the type is
FooBar but can't tell you that your cast on object will.

There is no reason to break existing behavior here, and a warning is
certainly not warranted. An error is when the type you request doesn't match T of any IEnumerable<T> that is available, but thats a different matter
entirely.

If I have a list<string> and I write foreach (ListViewItem in list) this
invokes a compiler error,
sure, but thats another matter as you already noticed.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[J.Marsch]

> Please reread my posting. there is an implicit cast from Foo to Foobar
with

will cause an exception.
Yah, I read that. I probably wasn't specific enough in my reply:
You have an array of IFoo that is filled with Foo objects, and you are
casting them to a FooBar.

With an array, you might be casting from Foo to FooBar because the compiler
optimizes out the enumerator. But with most collections, you are really
casting from Object to FooBar. This is because the enumerator returns type
Object, as defined in IEnumerator.Cur rent;

Now, I sort of see your point. Except from where I'm sitting, the real
issue is
semantics. Because I know that IEnumerator.Cur rent returns type Object, I
consider every foreach() statement to include an _explicit_ cast (from
object to something). Knowing about IEnumerator, that's just how I "parse"
the code in my head as I'm reading it. So when I read your initial post,
it seemed to me that every foreach would generate a compiler warning (except
for foreach(
object myObject in aCollection)

I guess if you're not coming from that point of view, it makes the foreach
look as though it might sometimes be performing an implicit cast. I haven't
looked at the IL to proof it, but I think that it's more accurate to view
every foreach as including a cast, until/unless generics are applied to
enumerators.
"cody" <pl************ *************@g mx.de> wrote in message
news:u$******** ******@tk2msftn gp13.phx.gbl...

I'm not sure that I follow your argument, but I'd like to understand it
better. The code example that you created would be invalid with or

without

generics. I only see an explicit cast in the code (technically, it's
probably from object to FooBar, because the enumerator probably returns
object)

Please reread my posting. there is an implicit cast from Foo to Foobar

with will cause an exception.

But see how dangerous foreach is: even if pointed to the problem people do
not see the invalid cast :)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[J.Marsch]

Cody:

A collection of object might be reaching a little, but I can definitely see
a heterogeneous collection. You might be accessing objects polymorphically .
If you want to see an example of that, you need look no further than
Winforms. System.Windows. Forms.Control.C ontrols (returns a collection of
controls that are owned by the control. They all derive from Control, but
some could be textboxes, some could be buttons, radio buttons, etc). A
generic collection of Collection<Text box> would not be sufficient.

While this is not quite the same thing as a collection of object, the
semantics are pretty close: a collection of objects that are of the same
base class, but are heterogeneous in nature. The same type of foreach error
would be possible:

// assuming that this code is in a member method of a form
foreach(Textbox in this.Controls) // oops -- blows up on the first
non-textbox in the controls collection
{}
"cody" <no************ ****@gmx.net> wrote in message
news:eN******** ******@tk2msftn gp13.phx.gbl...

foreach does implicitly cast every object in the collection to the
specified
taget type without warning.
Without generics this behaviour had the advantage of less typing for us since casting was neccessary in nearly every collection. But with generics I
consider this feature of foreach as dangerous. Casting is now almost
always
unwanted.

interface IFoo{}
class Foo:IFoo{}
class FooBar:IFoo{}

IFoo[] fooarray = {new Foo()} ;

foreach (FooBar in fooarray) // oops InvalidCastExce ption
{
}

My proposal is now that foreach should in future emit a compiler warning if
implicit cast would occur.
The problem is that, without generics, you don't have a choice. And, sorry to say it, assuming that everything will be generic is short sighted.

Tell me one reason why to use collections containing objects.
This should only be used very very rarely and with lots ofconsideration
done.

You
will have to deal with collections typed as object for a long time to

come.

foreach isn't dangerous in itself, its the developers fault if anything
fails, especially consdiering you defined the type and should be aware

that

means a cast. If you have a collection that isn't strongly typed and you

are

concerned it may hold incorrect data, you should be using for and as.

Strictly speaking, there is no such thing like "strongly typed". If a have

a conventional list, it can contain object and all of its descendants.
If I have a list<IFoo> it can contain IFoo and *all* of its implementing
classes.

Maybe we have to invent a new feature will really allows "very strongly
typed" collections, so that exactly one certain type is allowed, but this
cannot be caught by the compiler.

Having said that, the compiler should catch you if you use a type that an IEnumerable<T> cannot cast or convert to.
As I said the compiler won't complain it an implicit cast from baseclass

to descentant will take place which *may* be valid, or may not.

Which, frankly, is the desired behaviour.

I have to disagree.

Just throwing a warning if an implicit cast *may* happen on a
enumerator typed object is silly when the compiler can tell you that your generic enumerator *cannot* perform the cast you want when the type is
FooBar but can't tell you that your cast on object will.

There is no reason to break existing behavior here, and a warning is
certainly not warranted. An error is when the type you request doesn't

match

T of any IEnumerable<T> that is available, but thats a different matter
entirely.

If I have a list<string> and I write foreach (ListViewItem in list) this
invokes a compiler error,
sure, but thats another matter as you already noticed.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk