I would find Foo* very confusing if it would be used for IEnumerable<Foo>. Foo* is a pointer and incrementing that pointer means that we move to the next element that sits nearby in memory. With IEnumerable that isn't true... there shouldn't be any Count in IEnumerable too. There's no guarantee that you can count the elements that are returned by the interface: it might be a live stream that is returned frame by frame.
-
Follow
Oops, something didn't work.
Sign In to be begin to follow this thread
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.Getting "follow" information
Start following this thread
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.Removing your "follow"
Setting up your "follow"
Did you know you can
sign up for email notifications?
-
littleguru
<3 Seattle
-
Yggdrasil
Pour me a cab, 'cause I can't drink no more.
If you're a C# developer, you quickly outgrow the "* as pointer" instinct. I haven't touched pointers in quite a while, and this is true even though I've written some C++ code lately - I've mostly used ^ managed pointers for C++/CLI.littleguru said:I would find Foo* very confusing if it would be used for IEnumerable<Foo>. Foo* is a pointer and incrementing that pointer means that we move to the next element that sits nearby in memory. With IEnumerable that isn't true... there shouldn't be any Count in IEnumerable too. There's no guarantee that you can count the elements that are returned by the interface: it might be a live stream that is returned frame by frame.
Regardless of whether you use * or any other mark that won't send C/C++ programmers into a tizzy, it has nothing to do with IEnumerable's Count method. While it's true that an IEnumerable is a lazy construct that isn't required to know at any given point in time how many elements it has in its possibly infinite sequence, there are still many (dare I say most?) scenarios where the Count is both knowable and relevant. I would rather have a Count() method that can (potentially) throw an exception or return a special value for an unknowable length, rather than disallow it entirely. -
evildictaitor
I'll live forever, or die trying!
No - C# has pointers, even if you don't use them, so C# couldn't introduce Type* as a shorthand for IEnumerable<Type> without a breaking change (and unsafe contexts are important for C# - they're used everywhere inside the .NET framework even if you can't see them).Yggdrasil said:
If you're a C# developer, you quickly outgrow the "* as pointer" instinct. I haven't touched pointers in quite a while, and this is true even though I've written some C++ code lately - I've mostly used ^ managed pointers for C++/CLI.littleguru said:*snip*
Regardless of whether you use * or any other mark that won't send C/C++ programmers into a tizzy, it has nothing to do with IEnumerable's Count method. While it's true that an IEnumerable is a lazy construct that isn't required to know at any given point in time how many elements it has in its possibly infinite sequence, there are still many (dare I say most?) scenarios where the Count is both knowable and relevant. I would rather have a Count() method that can (potentially) throw an exception or return a special value for an unknowable length, rather than disallow it entirely.You might be able to "outgrow" the notion that Type* is a pointer, but that doesn't mean everyone can.
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.