Comment Feed for How about some syntax sugar for IEnumerable<>? (TechOff on Channel 9)

Re: Re: Re: How about some syntax sugar for IEnumerable?

evildictaitor — Fri, 19 Dec 2008 19:45:00 GMT

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.

Re: Re: How about some syntax sugar for IEnumerable?

Yggdrasil — Fri, 19 Dec 2008 19:09:54 GMT

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

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.

Re: How about some syntax sugar for IEnumerable?

Christian Liensberger — Fri, 19 Dec 2008 18:32:01 GMT

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.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

Christian Liensberger — Fri, 19 Dec 2008 18:29:25 GMT

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 :P or Boolean.

Re: Re: Re: How about some syntax sugar for IEnumerable?

stevo_ — Wed, 17 Dec 2008 14:19:24 GMT

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.

Re: Re: How about some syntax sugar for IEnumerable?

Yggdrasil — Wed, 17 Dec 2008 14:11:11 GMT

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

Re: How about some syntax sugar for IEnumerable?

William Stacey — Wed, 17 Dec 2008 01:54:26 GMT

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.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

Sven Groot — Sat, 13 Dec 2008 15:01:45 GMT

I was only making a minor point. Someone suggested that int, bool and array [] notation get special language keywords, and made the leap to assuming this was because they were someone "preferred" types, rather than for other more boring implementation reasons.

But that's my point: that's not true. There is no implementation difference between int and Int32, not at the level of the C# compiler. The CLR probably does have a separate notion of a hardware integer, but that has no relation to the int keyword, and no relation to C# whatsoever. The only reason they get special keywords is because that's what programmers are used to in C-like languages.

I'm not trying to be argumentative or anything (although I probably sound like that), just trying to get everyone on the same page, because it just seems we're talking about different things.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

evildictaitor — Sat, 13 Dec 2008 14:19:15 GMT

I was only making a minor point. Someone suggested that int, bool and array [] notation get special language keywords, and made the leap to assuming this was because they were someone "preferred" types, rather than for other more boring implementation reasons.

Sometimes I feel that trying to refute or explain things by giving examples doesn't help. Perhaps next time I will just say "No, you're wrong" and leave it at that, but it feels kind of rude. I was only trying to help.

Re: Re: Re: Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

Sven Groot — Sat, 13 Dec 2008 12:30:38 GMT

I wasn't claiming anything of the sort.

Then why did you change the subject? Everybody else was talking about C# up to that point. And as far as C# is concerned, Int32 and int and 100% identical. How that's handled internally by the CLR was never the matter at hand.

From a language perspective, int and Int32 are identical. No matter which you use, if you look at the generated code in ildasm or reflector, it'll be identical. Of course at some layer the CLR has to distinguish between Int32 and an actual hardware integer. But C# does not expose that.

Re: Re: Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

evildictaitor — Sat, 13 Dec 2008 10:53:41 GMT

I wasn't claiming anything of the sort. While they are identical to all intents and purposes, they are not unified into a single entity because they are NOT the same in the corelib, where they are different things for the purposes of allowing the object methods on an int to be definable (Note that Java doesn't do this, so you can't have something like "4.ToString()"). My point is simply that the duplication of int and Int32 isn't quite as arbitrary as it was being made out to be - there is a reason for it, and that the argument that a duplication of syntax of IEnumerable<T> is something they've done before for code simplicity is therefore a flawed argument.

The reason that Int32 and int are the same in all other libraries and code is because the compiler converts all cases of Int32 to int and all cases of typeof(int) to typeof(Int32), and the IDE treats both identically - since I suspect most people don't make a habit of re-engineering the corelib or building compilers, most .NET developers can happilly live thinking that Int32 and int are identically equivilent.

Re: Re: Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

JonathonW — Sat, 13 Dec 2008 06:39:42 GMT

Gah, now you've gotten me stumped, looking through the CIL docs trying to figure out what the frack they're doing there (where int32 is a member of System.Int32, and they're both value types). int32 is supposed to directly map to System.Int32 in CIL, too, so it shouldn't be possible for it to be a member of itself.

There must be a good explanation...

Re: Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

Sven Groot — Sat, 13 Dec 2008 03:40:04 GMT

The underlying implementation is not the issue. You were saying that they are different from a C# language perspective, which they're not. Whether you use Int32 or int doesn't matter, it generates identical IL.

Re: Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

Chris Walker — Fri, 12 Dec 2008 21:11:40 GMT

I would accept an alias like “ien” for IEnumerable. However, since readability is a matter of personal preference then maybe a C++ macro definition is what is really called for. After all, there’s quite a few lengthy type names that could fall into the same category.

Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

evildictaitor — Fri, 12 Dec 2008 19:10:38 GMT

Except in the Core Library (mscorlib), where an Int32 is a struct that contains an int and exposes object methods; whereas int is just the pure numeric type. Int32 is a struct that contains an int field; something that would not be allowed normally since a structure can't recursively contain fields on itself.

Re: How about some syntax sugar for IEnumerable?

stevo_ — Fri, 12 Dec 2008 15:51:55 GMT

The way I was always told is that int, bool string etc in C# are there so that technically the C# language could be made to sit on top of something that wasn't nec~ .NET.. same reasons why C# looks for GetEnumerator, and expects only certain methods / properties to exist on the returned object (various other things like that).. it doesn't (or at least isn't suposed to) have any specific knowledge of .NET types.

Re: Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

Curt Nichols — Fri, 12 Dec 2008 14:39:04 GMT

Correct, as Sven mentioned in C# int is just an alias for Int32. You can spell it either way you wish. Under the covers int is an Int32.

Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

Yggdrasil — Fri, 12 Dec 2008 14:22:38 GMT

I always assumed that Int32/int swapping is identical to Object/object and String/string, i.e. just an alias that the compiler resolves to the same thing. When the compiler encounters an "int a = 5" call, doesn't it translate it to an an Int32 and then assigns the value to the _value field?

Re: Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

Sven Groot — Fri, 12 Dec 2008 14:18:17 GMT

int and Int32 are nessisarilly different (this is to do with the fact that int is a primitive that supports basic operations, whereas Int32 is a primitive structure that supports all of the .-methods

That is true in Java, but not in C#; in C#, "int" is an alias for System.Int32, nothing more.

Re: Re: Re: Re: How about some syntax sugar for IEnumerable?

evildictaitor — Fri, 12 Dec 2008 14:00:58 GMT

There's good reason for the examples you give ( arrays, int versus Int32 ) that are systemmic and to do with how the CLR and C# actually operate in terms of low level mechanics, so while what you say is certainly true, IEnumerable<T> _can_ exist on its own - int and Int32 are nessisarilly different (this is to do with the fact that int is a primitive that supports basic operations, whereas Int32 is a primitive structure that supports all of the .-methods. The compiler is happy to swap between them, but the struct Int32 contains an (int _value) field, and arrays need special dispensation from the Garbage Collector and special creation semantics at the runtime.

That's not to say that your idea isn't good - it's just to say that IEnumeable<T> doesn't HAVE to have a new keyword, wheras int and arrays DO.

Re: Re: Re: How about some syntax sugar for IEnumerable?

Yggdrasil — Wed, 10 Dec 2008 15:47:31 GMT

Auto-expanding var might aid writing, but not reading. Heavily nested generics are hard to read, for me - but I'm not arguing that var can be even harder to parse. We decided to enforce as a coding standard at using var only when the full, specific and concrete type name is specified on the same line (i.e. var dict = new Dictionary<int, string>). If we initialize an object from a method, factory or anything else, we specify the full type name.

Regarding your second point - when you start relying on LINQ a lot, IEnumerable<T> becomes a de-facto language keyword. Just like int and bool are defined as language keywords for the oh-so-common Int32 and Boolean, to name a few. Or, to be even more similar, the [] array specifier.

Re: How about some syntax sugar for IEnumerable?

stevo_ — Wed, 10 Dec 2008 15:33:34 GMT

Yes we all know this, but clearly what everyone is talking about here is having immutable interfaces as a step in the middle of IEnumerable and IWhateverMutableDataStructure...

I'm still trying to understand why thats so hard to grasp.. nobody is wanting to corrupt what IEnumerable is.. we just want interfaces that describe the readonly actions of the common data structures that .NET has.. this is something I'm sure most people here have thought about even years ago.. I was thinking this time last year that I would love an immutable collection / dictionary interface.. and then wondering why they don't exist.. the great thing about the interface over the concrete type say.. ReadOnlyCollection.. is:

- Allows complete variance on implementation
- Allows you to expose the instance as either readonly or mutable in a cleaner way (vs keeping a reference to the underlying Collection that ReadOnlyCollection wraps)..

Re: Re: How about some syntax sugar for IEnumerable?

evildictaitor — Wed, 10 Dec 2008 15:28:48 GMT

I would prefer the IDE to auto-expand out my "var" keywords to what they really are when I give it a shortcut key - this would allow you to just write

var myFoo = select ... <Tab> <Tab> <ShortCutKey>

IEnumerable<ICollection<Structure<MyFoo<Dictionary<Gets<Quite<Long>, Doesnt> It>>...>> myFoo = select ...

Actually adding keywords dilutes the language and makes it harder to read.

Re: Re: How about some syntax sugar for IEnumerable?

evildictaitor — Wed, 10 Dec 2008 15:25:59 GMT

IEnumerable<T> has no direct methods for mutating a collection, so unless you use reflection or do an upwards cast then an IEnumerable<T> is immutable.

If you want to be really sure, then do this:

class {
List<foo> myMutableCollection = new List<foo>();

  public IEnumerable<foo> EnumerableFoo {
   get {
   return new ReadOnlyCollection(myMutableCollection);
   }
  }
}

and now the mutablecollection can only be altered by the class or by reflection (and there's not much you can do to prevent reflection doing bad things)

Re: How about some syntax sugar for IEnumerable?

Yggdrasil — Wed, 10 Dec 2008 08:30:05 GMT

To get back to the original topic - I'm all for the proposed syntax change. When you start using LINQ a lot, passing IEnumerable<T>s back and forth, you start hating how long it is - not to write, since we have autocomplete intellisense for that, but to read. It fills up the code with useless letters.

I second the * syntax, though that would cause problems with unsafe code. A coworker of mine wants to just tack the plural 's' onto it, so an IEnumerable<string> would just be strings. Of course, that would mean that an IEnumerable<Bus>, for instance, would have to be correctly parsed by the compiler from Buses. And that's before we even make the compiler understand the shorthand for IEnumerable<Mouse>...