Stretching Type Inference

Reflective Perspective - Chris Alcock » The Morning Brew #81

Reflective Perspective - Chris Alcock » The Morning Brew #81 — Fri, 25 Apr 2008 07:30:33 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #81

re: Stretching Type Inference

Paulo Morgado — Thu, 24 Apr 2008 21:38:35 GMT

In fact, some type inference occurs when you don't specify the type parameter, but it's because you already did it somewhere before.

I've also considered "private var" instead of just "private" but came to the conclusion that it's not needed.

When defining a local variable "var" is needed to desambiguate if you are defining a variable or assigning a previous defined variable or parameter, which doesn't occur when defining a field. In fact, there are people that think "var" should not exist, but I don't agree with that.

re: Stretching Type Inference

Justin Lee — Thu, 24 Apr 2008 16:17:15 GMT

With regards to the "Method Output And Parameter Type Inference", technically we could already do so with Generic Methods and Generic Parameters.

   private bool CreateList<T>(out T list)
   {
      list = new T();
      return true;
   }
   private void ProcessList<T>(ref T list)
   {
         // ...
   }
   private T TransformList<T>(T list)
   {
      return list;
   }

Or something along those lines.

And might I add it probably would be syntactically correct if this line:

   private listOfStuff = new List<Stuff>();

was like this instead:

   private var listOfStuff = new List<Stuff>();

But definitely, I would like to see "var" being stretched to its limits in terms of type inference. It would be interesting to see how much we can infer statically, instead of going dynamic.

re: Stretching Type Inference

Paulo Morgado — Thu, 24 Apr 2008 08:15:14 GMT

Hi Bart,

I just let my mind run wild from something that looked nice and useful to the scary places it could lead us to. :)

re: Stretching Type Inference

Bart — Thu, 24 Apr 2008 06:57:02 GMT

Hi Paulo,

Some nice thoughts but there seem to be tons of things that make this rather difficult to say the least.

My main concern is the fact that a sole "new()" doesn't have a type as all expressions in C# do today. This would require type information to flow in the opposite direction, which it never did and IMO never should. It's similar to why LINQ has the from clause first in order to make the type information flow naturally.

To point out a concrete problem:

   public void SomeMethod()
   {
       AnotherMethod(new());
   }
   private void AnotherMethod(List<string> arg)
   {
       // ...
   }

will break as soon as you get new conflicting overloads for AnotherMethod which makes reasoning about code really hard. Every time you add a method you risk breaking something somewhere else (luckily you didn't make it public :-)). Also refactoring becomes trickier, e.g. when you decide to switch a "type-inferred field" from a concrete class to an abstract class or interface.

With things like:

  Point p = new(1, 1);

and

  Dictionary<Point, Stack<Person>> v = new();

I can somewhat symphatize, and you could get rid of the " = new" portion in there but then we get dangerously close to C's syntax which would at the very least be confusing because of semantic differences.

Cheers,

-Bart

Stretching Type Inference

DotNetKicks.com — Thu, 24 Apr 2008 00:05:25 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com