Tech Off Thread

57 posts

How about some syntax sugar for IEnumerable<>?

Back to Forum: Tech Off
  • User profile image
    Yggdrasil

    evildictaitor said:
    Yggdrasil said:
    *snip*
    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.

    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.

  • User profile image
    evildictait​or

    Yggdrasil said:
    evildictaitor said:
    *snip*

    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.

    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.

  • User profile image
    Sven Groot

    evildictaitor said:
    Yggdrasil said:
    *snip*
    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.
    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.

  • User profile image
    Yggdrasil

    evildictaitor said:
    Yggdrasil said:
    *snip*
    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.

    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?

  • User profile image
    Curt Nichols

    Yggdrasil said:
    evildictaitor said:
    *snip*

    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?

    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.

  • User profile image
    stevo_

    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.

  • User profile image
    evildictait​or

    Sven Groot said:
    evildictaitor said:
    *snip*

    That is true in Java, but not in C#; in C#, "int" is an alias for System.Int32, nothing more.
    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. 

  • User profile image
    longnightmo​on

    Curt Nichols said:
    Yggdrasil said:
    *snip*
    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.
    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.

  • User profile image
    Sven Groot

    evildictaitor said:
    Sven Groot said:
    *snip*
    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. 
    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.

  • User profile image
    Cannot​Resolve​Symbol

    Sven Groot said:
    evildictaitor said:
    *snip*
    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.
    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...

  • User profile image
    evildictait​or

    Sven Groot said:
    evildictaitor said:
    *snip*
    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.
    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.

  • User profile image
    Sven Groot

    evildictaitor said:
    Sven Groot said:
    *snip*
    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.
    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.

  • User profile image
    evildictait​or

    Sven Groot said:
    evildictaitor said:
    *snip*

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

  • User profile image
    Sven Groot

    evildictaitor said:
    Sven Groot said:
    *snip*
    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.
    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.

  • User profile image
    staceyw

    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. 

  • User profile image
    Yggdrasil

    staceyw said:
    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. 
    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>.

  • User profile image
    stevo_

    Yggdrasil said:
    staceyw said:
    *snip*
    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>.
    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.

  • User profile image
    littleguru

    Sven Groot said:
    evildictaitor said:
    *snip*

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

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.