Programming without Types


Warning, actual serious content.  This is not a joke.  Repeat, this is not a joke.


I don't want to get rid of types. I just don't want to have to explicitly say them all the time.  I want more type inference in the language.  Again, this is not some lead in to another silly post making fun of type inference.  I actually like type inference to some degree.  I want more of it.


Where do I want it?  First off, I want it in my foreach statement.  Why do I have to specifically call out the type of my iteration variable.  I should be able to deduce it from the collection.  Sure, back in olden days of .Net you could not determine the appropriate element type unless you had written up a special collection class with a special strongly-typed enumerator.  But now, in the next release everything is generics.  You've got generic interfaces for IEnumerable/IEnumerator.  They always know the element type, always.  So, foreach, my friend, why do I still have to re-state the element type?


Instead of:     foreach(Foo f in foos) { ... }


Why not:       foreach(f in foos) { ... }


The local 'f' is still strongly typed.


Better right?  Well, I did after all convert the X# compiler to work this way.  Maybe one day you'll see it in C-omega, whenever that research compiler finds it way into the wild.  It would be fantastic, IMO, if C# could do this.


Where else would you get rid of typing the type in C#, if you could?


Matt

Comments (14)

  1. jaybaz [MS] says:

    They were talking about doing this in C# 2.0, as part of the inference that comes with Generic functions.

    One of the reasons they backed off is because it makes the work of C# Intellisense much harder: we have to figure out all the complex inference rules correctly just to give you basic completion lists, and we have to do it in "real time".

    One place I would have liked to see the language be more explicit is with the type of an anonymous method:

    anEvent += delegate D (object sender) { … };

    The editing experience would be nicer. As soon as you hit SPACE after the ‘delegate’, a completion list pops up with all delegate types. In this context, we would preselect the type of ‘anEvent’. After you select one, we generate the signature of that delegate for you.

    It would make my team’s life easier, for sure.

  2. Jerry Pisk says:

    You’re forgetting one thing – your NOW is definitelly not now, and probably not even in the near future (few months). I want people to handle issues in an existing product, not be focused on something that’s not released.

    As for not using types – why not? The foreach loop variable doesn’t have to be of the same type that the collection holds, not even with generics. Let’s say you want to serialize all elements in the collection, so you iterate ISerializable type, not the actual element type.

  3. Matt,

    i’m not sure about this: the type does make things a lot easier to read…

    e.g.:

    void foo( INode node)

    {

    node2 = node;

    }

    obviously, node2 is of type INode here. or is it some instance variable of some derived type? or ‘object’?

    i really think

    INode node2 = …

    or

    object node2 = …

    is making things a lot clearer for everybody else (which in alotofcases will include the original coder :))

    WM_MY0.02$

    thomas woelfer

  4. Matt says:

    I was not suggesting getting rid of the ability to express the type, just making it optional in some cases. Not specifying the type in a local variable declaration/initialization makes it hard to figure out that what you are looking at is actually a local variable declaration/initialization. So that wouldn’t be good. Though maybe there is another way that is good.

  5. Matt,

    The declaration of the type in the foreach statement is, for me, more intuitive, since it is in a way a declaration of a new local variable.

    In my mind,

    foreach (Foo f in foos) { … }

    translates to:

    Foo f;

    foreach (f in foos) { … }

    If you remove the type, it would be as if the variable was never defined.

    But then again, this is just nitpicking.

    Omer

  6. Cory Smith says:

    Why not just use VB.NET?

    If you turn turn off Option Strict and Option Explicit, you can do the following:

    list = New ArrayList

    a = 1

    b = "2"

    list.Add(a)

    list.Add(b)

    list.Add(a + b)

    For Each value In list

    MsgBox(value)

    Next

    …and it will work just fine. Notice I did not declare the list, a or b variables. I also am adding a string and a numeric value together. Everything in this code is inferred.

    VB has been doing this for years… and you know what… it’s *A BAD THING*!!!!! Just ask anyone who hates VB 😉

  7. Matt says:

    With VB in that mode, nothing is actually inferred. It is just untyped.

  8. Cory Smith says:

    I showed this to someone else and the pointed out a good point about the fact that I was taking it too far to the extreme. And, Matt points out that it’s untyped… so…

    Dim integers As New IntegerCollection

    integers.Add(1)

    integers.Add(2)

    integers.Add(3)

    For Each i In integers

    ..If TypeOf i Is Int16 Then

    ….MsgBox(i)

    ..End If

    Next

    You will see 3 message boxes appear… and at no point did I ever say that i was an int16.

    The IntegerCollection is a sample Int16 collection taken directly from the online help when you look up CollectionBase.

    Note, periods added to preserve tabs 😉

  9. Matt says:

    Woah! That’s it. VB has it, and I want it. Maybe I signed up for the wrong gig. Maybe VB is the holy land after all.

  10. Joe Surfer says:

    Sounds like maybe you want to use a ML language like O’CaML, or SML.NET or F#. Those languages infer the type at compile time, like you would like C# to do.

  11. Richard@Home says:

    I can remember reading an article bundled on an old (VB6) tech cd about using variants (VB’s untyped datatype) for EVERYTHING.

    I started off thinking, this man is MAD and finished up agreeing with him completely.

    One of the best examples I can think of is handling Nulls. You can’t store (or test for) a Null in a regular typed variable and an empty string is not the same as a Null.

    These days, I develop mainly for the web in PHP which is also untyped and I can’t say I miss typed variables much. You don’t even have to declare their usage in advance, just get on and write the code.

  12. J. Daniel Smith says:

    C++ is exploring some of these ideas; see http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1607.pdf

  13. Mark Allan says:

    ‘Ere, can’t we just cheat and do this with Intellisense?

    e.g. on typing

    foreach (f in foos

    Intellisense would pop up "foreach (Foo f in foos) (Press TAB to insert)".

    I know it doesn’t quite fit the standard Intellisense behaviour of only working at the insertion point, but who cares if it saves us typing 3 characters?

    P.S.

    IntegerCollection integers = new IntegerCollection();

    integers.Add(1);

    integers.Add(2);

    integers.Add(3);

    foreach (object i in integers)

    ..if (i is int)

    ….MessageBox.Show(i.ToString());

    Personally, I think Fortran had the right idea 🙂

Skip to main content