How about some syntax sugar for IEnumerable<>? | Tech Off

staceyw
Before C# there was darkness...

Not sure I see any readability issues with IEnumerable<T>. In fact, with linq, many people now come to expect it, so in that sense, people understand it right away and "get" the contract. So it is also a pattern you don't have to reinvent. It also gives you the ability of lazy yielding and makes that very easy, so in that respect it is already sugar. I think finding something else just makes learning something else with another name.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

In reply to staceyw

#Dec 16th, 2008 @ 5:54 PM

But like the natural evolution of spoken languages, you find that conceptts that are in heavy use often get shortened down, either 'officially' or colloquially, simply because they are in constant use and people try to optimize their communications. With LINQ, as you said, people use it a lot, and a good thing too in my opinion. That's why people will want a simpler shorthand for it rather than the relatively lengthy an verbose IEnumerable<T>.

stevo_
Human after all

In reply to Yggdrasil

#Dec 17th, 2008 @ 6:11 AM

The only reason I think it could be done is so that C# has the ability to describe a sequence without reliance on .NET types... it already has this in a senses however from its GetEnumerator() pattern etc.

littleguru
<3 Seattle

In reply to Sven Groot

#Dec 13th, 2008 @ 7:01 AM

Hehe... how much do I love these kind of arguments. It's actually rather easy to see what "int" gets resolved in C# to: type int into the C# editor. Select it. Press F12. See where you end... the same applies to bool, byte, long, short, and a lot others. just keywords to make it easier for C/C++ devs and who wants to type Int32 all the time Tongue Out

or Boolean.

littleguru
<3 Seattle

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.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

In reply to littleguru

#Dec 19th, 2008 @ 10:32 AM

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. Smiley

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
if( !succeed( try() ) ) { while(true) try(); }

In reply to Yggdrasil

#Dec 19th, 2008 @ 11:09 AM

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).

You might be able to "outgrow" the notion that Type* is a pointer, but that doesn't mean everyone can.