After discussion with colleagues regarding the use of the &#39;var&#39; keyword in C# 3 I wondered what people&#39;s opinions were on the appropriate uses of type inference via var?

For example I rather lazily used var in questionable circumstances, e.g.:-

    foreach(var item in someList) { // ... } // Type of &#39;item&#39; not clear.
    var something = someObject.SomeProperty; // Type of &#39;something&#39; not clear.
    var something = someMethod(); // Type of &#39;something&#39; not clear.

More legitimate uses of var are as follows:-

    var l = new List&lt;string&gt;(); // Obvious what l will be.
    var s = new SomeClass(); // Obvious what s will be.

Interestingly LINQ seems to be a bit of a grey area, e.g.:-

    var results = from r in dataContext.SomeTable
                  select r; // Not *entirely clear* what results will be here.

It&#39;s clear what results will be in that it will be a type which implements IEnumerable&lt;RowType&gt;, however it isn&#39;t entirely obvious in the same way a var declaring a new object is.

It&#39;s even worse when it comes to LINQ to objects, e.g.:-

    var results = from item in someList
                  where item != 3
                  select item;

This is no better than the equivilent foreach(var item in someList) { // ... } equivilent.

There is a real concern about type safety here - for example if we were to place the results of that query into an overloaded method that accepted IEnumerable&amp;lt;int&amp;gt; and IEnumerable&amp;lt;double&amp;gt; the caller might inadvertently pass in the wrong type.

`var` *does* maintain strong typing but the question is really whether it&#39;s dangerous for the type to not be immediately apparent on definition, something which is magnified when overloads mean compiler errors might not be issued when you unintentionally pass the wrong type to a method.

Use of var keyword in C#

I have an array that is made up of `AnyObject`. I want to iterate over it, and find all elements that are array instances.

How can I check if an object is of a given type in Swift?


Checking if an object is a given type in Swift

I&#39;m having some trouble navigating Java&#39;s rule for inferring generic type parameters. Consider the following class, which has an optional list parameter: 

    import java.util.Collections;
    import java.util.List;
    
    public class Person {
      private String name;
      private List&lt;String&gt; nicknames;
      
      public Person(String name) {
        this(name, Collections.emptyList());
      }
      
      public Person(String name, List&lt;String&gt; nicknames) {
        this.name = name;
        this.nicknames = nicknames;
      }
    }

My Java compiler gives the following error:

    Person.java:9: The constructor Person(String, List&lt;Object&gt;) is undefined

But `Collections.emptyList()` returns type `&lt;T&gt; List&lt;T&gt;`, not `List&lt;Object&gt;`. Adding a cast doesn&#39;t help

    public Person(String name) {
      this(name,(List&lt;String&gt;)Collections.emptyList());
    }

yields

    Person.java:9: inconvertible types

Using `EMPTY_LIST` instead of `emptyList()` 

    public Person(String name) {
      this(name, Collections.EMPTY_LIST);
    }

yields 

    Person.java:9: warning: [unchecked] unchecked conversion

Whereas the following change makes the error go away:

    public Person(String name) {
      this.name = name;
      this.nicknames = Collections.emptyList();
    }

Can anyone explain what type-checking rule I&#39;m running up against here, and the best way to work around it? In this example, the final code example is satisfactory, but with larger classes, I&#39;d like to be able to write methods following this &quot;optional parameter&quot; pattern without duplicating code.

For extra credit: when is it appropriate to use `EMPTY_LIST` as opposed to `emptyList()`?

Collections.emptyList() returns a List&lt;Object&gt;?

I&#39;ve been using the new `auto` keyword available in the C++11 standard for complicated templated types which is what I believe it was designed for. But I&#39;m also using it for things like:

    auto foo = std::make_shared&lt;Foo&gt;();

And more skeptically for:

    auto foo = bla(); // where bla() return a shared_ptr&lt;Foo&gt;

I haven&#39;t seen much discussion on this topic. It seems that `auto` could be overused since a type is often a form of documentation and sanity checks. Where do you draw the line in using `auto` and what are the recommended use cases for this new feature?

To clarify: I&#39;m not asking for a philosophical opinion; I&#39;m asking for the intended use of this keyword by the standard committee, possibly with comments on how that intended use is realized in practice.

How much is too much with C++11 auto keyword?

I&#39;m using Xcode 6 Beta 6.

This is something that&#39;s been bugging me for some time now, but it&#39;s reaching a point where it&#39;s barely usable now.

My project is starting to have a _decent_ size of 65 Swift files and a few bridged Objective-C files (which are really not the cause of the problem).

It seems like any slight modification to any Swift file (like adding a simple white space in a class that&#39;s barely used in the app) will cause the entire Swift files for the specified target to be recompiled.

After a deeper investigation, I&#39;ve found that what is taking pretty much 100% of the compiler time is the `CompileSwift` phase where Xcode runs the `swiftc` command on all Swift files of your target.

I did some further investigation, and if I only keep the app delegate with a default controller the compilation is very fast, but as I was adding more and more of my project files, the compile time was starting to get really slow.

Now with only 65 source files, it takes about 8/10 seconds to compile each time. Not very _swift_ at all.

I haven&#39;t seen any post talking about this issue except [this one][1], but it was an old version of Xcode 6. So I&#39;m wondering if I&#39;m the only one in that case.

**UPDATE**

I&#39;ve checked a few Swift projects on [GitHub][2] like [Alamofire][3], [Euler][4] and [CryptoSwift][5], but none of them had enough Swift files to actually compare. The only project I found that was starting a have _decent_ size was [SwiftHN][6], and even though it only had a dozen source files I was still able to verify the same thing, one simple space and the whole project needed recompilation which was starting to take a little time (2/3 seconds).

Compared to Objective-C code where both analyzer and compilation are blazing fast, this really feels like Swift will never be able to handle big projects, but please tell me I&#39;m wrong.

**UPDATE With Xcode 6 Beta 7**

Still no improvement whatsoever. This is starting to get ridiculous. With the lack of `#import` in Swift, I really don&#39;t see how Apple will ever be able to optimize this.

**UPDATE With Xcode 6.3 and Swift 1.2**

Apple has added [incremental builds][7] (and many other compiler optimizations). You have to migrate your code to Swift 1.2 to see those benefits, but Apple added a tool in Xcode 6.3 to help you do so:

![Enter image description here][8]

**HOWEVER**

Don&#39;t rejoice too quickly as I did. The graph solver that they use to make the build incremental is not very well optimised yet.

Indeed first, it doesn&#39;t look at function signature changes so if you add a space in the block of one method, all files depending on that class will be recompiled.

Second, it seems to create the tree based on the files that were recompiled even if a change doesn&#39;t affect them. For example, if you move these three classes into different files

    class FileA: NSObject {
        var foo:String?
    }
    class FileB: NSObject {
        var bar:FileA?
    }
    class FileC: NSObject {
        var baz:FileB?
    }

Now if you modify `FileA`, the compiler will obviously mark `FileA` to be recompiled. It will also recompile `FileB` (that would be OK based on the changes to `FileA`), **but** also `FileC` because `FileB` is recompiled, and that is pretty bad because `FileC` never uses `FileA` here.

So I hope they improve that dependency tree solver... I&#39;ve opened a [radar][9] with this sample code.

**UPDATE With Xcode 7 beta 5 and Swift 2.0**

Yesterday Apple released the beta 5 and inside the release notes we could see:

&gt; Swift Language &amp; Compiler
• Incremental builds: changing just the body of a function should no longer cause dependent files to be rebuilt. (15352929)

I have given it a try and I must say it is working really (really !) well now. They greatly optimized the incremental builds in swift. 

I highly recommend you create a `swift2.0` branch and keep your code up to date using XCode 7 beta 5. You will be pleased by the enhancements of the compiler (however I&#39;d say the global state of XCode 7 is still slow &amp; buggy)

**UPDATE With Xcode 8.2**

It&#39;s been a while since my last update on this issue so here it is.

Our app is now about 20k lines of almost exclusively Swift code, which is decent but not outstanding. It underwent swift 2 and than swift 3 migration. It takes about 5/6m to compile on a mid 2014 Macbook pro (2.5 GHz Intel Core i7) which is okay on a clean build. 

However the incremental build is still a joke despite Apple claiming that:

&gt; Xcode will not rebuild an entire target when only small changes have occurred. (28892475)

Obviously I think many of us just laughed after checking out this nonsense (adding one private (private!) property to any file of my project will recompile the whole thing...)

I would like to point you guys to [this thread][10] on Apple developer forums which has some more information about the issue (as well as appreciated Apple dev communication on the matter once in a while)

Basically people have come up with a few things to try to improve the incremental build:

 1. Add a `HEADER_MAP_USES_VFS` project setting set to `true`
 2. Disable `Find implicit dependencies` from your scheme
 3. Create a new project and move your files hierarchy to the new one.

I will try solution 3 but solution 1/2 didn&#39;t work for us.

What&#39;s ironically funny in this whole situation is that looking at the first post on this issue we were using Xcode 6 with I believe swift 1 or swift 1.1 code when we reached the first compilations slugginess and now about two years later despite actual improvements from Apple the situation is just as bad as it was with Xcode 6. How ironic.

I actually **REALLY** regret choosing Swift over Obj/C for our project because of the daily frustration it involves. (I even switch to AppCode but that&#39;s another story)

Anyways I see this SO post has 32k+ views and 143 ups as of this writing so I guess I&#39;m not the only one. Hang in there guys despite being pessimistic over this situation there might be some light at the end of the tunnel.

If you have the time (and courage!) I guess Apple welcomes radar about this.

Til next time ! Cheers


**UPDATE With Xcode 9**

Stumble upon [this][11] today. Xcode quietly introduced a new build system to improve on the current awful performance. You have to enable it through the workspace settings.

[![enter image description here][12]][12]

Have given a try yet but will update this post after it&#39;s done. Looks promising though.


  [1]: https://stackoverflow.com/questions/24842995/swift-unwrapping-cause-swift-compile-slowly
  [2]: http://en.wikipedia.org/wiki/GitHub
  [3]: https://github.com/Alamofire/Alamofire
  [4]: https://github.com/mattt/Euler
  [5]: https://github.com/krzyzanowskim/CryptoSwift
  [6]: https://github.com/Dimillian/SwiftHN
  [7]: https://developer.apple.com/swift/blog/?id=22
  [8]: http://i.stack.imgur.com/DD0Ba.png
  [9]: http://www.openradar.me/radar?id=5853511405273088
  [10]: https://forums.developer.apple.com/thread/62737
  [11]: https://github.com/quellish/XcodeNewBuildSystem
  [12]: https://i.stack.imgur.com/PzjTN.png

Why is Swift compile time so slow?

Why is type inference not supported for constructors the way it is for generic methods? 

    public class MyType&lt;T&gt;
    {
       private readonly T field;
       public MyType(T value) { field = value; }
    }

    var obj = new MyType(42); // why can&#39;t type inference work out that I want a MyType&lt;int&gt;?

Though you could get around this with a factory class,

    public class MyTypeFactory
    {
       public static MyType&lt;T&gt; Create&lt;T&gt;(T value)
       {
          return new MyType&lt;T&gt;(value);
       }
    }
    var myObj = MyTypeFactory.Create(42);

Is there a practical or philosophical reason why the constructor can&#39;t support type inference?

Why can&#39;t the C# constructor infer type?

I have a generic function that calls a web service and serialize the JSON response back to an object.

    class func invokeService&lt;T&gt;(service: String, withParams params: Dictionary&lt;String, String&gt;, returningClass: AnyClass, completionHandler handler: ((T) -&gt; ())) {
        
                /* Construct the URL, call the service and parse the response */
    }

What I&#39;m trying to accomplish is is the equivalent of this Java code

    public &lt;T&gt; T invokeService(final String serviceURLSuffix, final Map&lt;String, String&gt; params,
                                   final Class&lt;T&gt; classTypeToReturn) {
    }


 - Is my method signature for what I&#39;m trying to accomplish correct?
 - More specifically, is specifying `AnyClass` as a parameter type the
   right thing to do?
 - When calling the method, I&#39;m passing `MyObject.self` as the returningClass value, but I get a compilation **error &quot;Cannot convert the expression&#39;s type &#39;()&#39; to type &#39;String&#39;&quot;**

&lt;!-- bullet, be-gone --&gt;


    CastDAO.invokeService(&quot;test&quot;, withParams: [&quot;test&quot; : &quot;test&quot;], returningClass: CityInfo.self) { cityInfo in /*...*/
        
    }

----

**Edit:** 

I tried using `object_getClass`, as mentioned by holex, but now I get:

&gt; error: &quot;Type &#39;CityInfo.Type&#39; does not conform to protocol &#39;AnyObject&#39;&quot;

What need to be done to conform to the protocol?

    class CityInfo : NSObject {
    
        var cityName: String?
        var regionCode: String?
        var regionName: String?
    }


How to pass a class type as a function parameter

It seems that `auto` was a fairly significant feature to be added in C++11 that seems to follow a lot of the newer languages. As with a language like Python, I have not seen any explicit variable declaration (I am not sure if it is possible using Python standards).

Is there a drawback to using `auto` to declare variables instead of explicitly declaring them?


Is there a downside to declaring variables with auto in C++?

I have come across a curious situation involving static generic methods. This is the code:

    class Foo&lt;E&gt;
    {
        public static &lt;E&gt; Foo&lt;E&gt; createFoo()
        {
            // ...
        }
    }
    
    class Bar&lt;E&gt;
    {
        private Foo&lt;E&gt; member;
    
        public Bar()
        {
            member = Foo.createFoo();
        }
    }

How come I don&#39;t have to specify any type arguments in the expression `Foo.createFoo()`? Is this some kind of type inference? If I want to be explicit about it, how can I specify the type argument?

Calling static generic methods

According to the [Scala Language Spec][1]:


&gt; ... local type inference is permitted to limit the complexity of inferred
&gt; bounds [of type parameters]. Minimality and maximality of types have to be understood
&gt; relative to the set of types of acceptable complexity.

In practice what are the limits? 

Also, are there different limits that apply to inferred expression types than to parameter type bounds, and what are those limits?

  [1]: http://www.scala-lang.org/docu/files/ScalaReference.pdf#page58

What limits does scala place on the &quot;acceptable complexity&quot; of inferred types?

I&#39;m working on a completion (intellisense) facility for C# in emacs. 

The idea is, if a user types a fragment, then asks for completion via a particular keystroke combination, the completion facility will use .NET reflection to determine the possible completions.  

Doing this requires that the type of the thing being completed, be known.  If it&#39;s a string, there&#39;s a known set of possible methods and properties; if it&#39;s an Int32, it has a separate set, and so on.  

Using semantic, a code lexer/parser package available in emacs, I can locate the variable declarations, and their types.  Given that, it&#39;s straightforward to use reflection to get the methods and properties on the type, and then present the list of options to the user. (Ok, not quite *straightforward* to do *within* emacs, but using [the ability to run a powershell process inside emacs][1], it becomes much easier. I write a custom .NET assembly to do reflection, load it into the powershell, and then elisp running within emacs can send commands to powershell and read responses, via comint.  As a result emacs can get the results of reflection quickly.)

The problem arrives when the code uses `var` in the declaration of the thing being completed. That means the type is not explicitly specified, and completion won&#39;t work. 

How can I reliably determine the actual type used, when the variable is declared with the `var` keyword?  Just to be clear, I don&#39;t need to determine it at runtime.  I want to determine it at &quot;Design time&quot;.

So far I have these ideas:

&lt;ol&gt;
&lt;li&gt;compile and invoke:
 
&lt;ul&gt;
&lt;li&gt;extract the declaration statement, eg `var foo = &quot;a string value&quot;;`&lt;/li&gt;
&lt;li&gt;concatenate a statement `foo.GetType();`&lt;/li&gt;
&lt;li&gt;dynamically compile the resulting C# fragment it into a new assembly &lt;/li&gt;
&lt;li&gt;load the assembly into a new AppDomain, run the framgment and get the return type.&lt;/li&gt;
&lt;li&gt;unload and discard the assembly&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;I know how to do all this.  But it sounds awfully heavyweight, for each completion request in the editor. &lt;/p&gt;
&lt;p&gt;
I suppose I don&#39;t need a fresh new AppDomain every time.  I could re-use a single AppDomain for multiple temporary assemblies, and amortize the cost of setting it
up and tearing it down, across multiple completion requests.  That&#39;s more a tweak of the basic idea.  
&lt;/p&gt;

&lt;/li&gt;

&lt;li&gt;compile and inspect IL    
&lt;p&gt;Simply compile the declaration into a module, and then inspect the IL, to determine the actual type that was inferred by the compiler.   How would this be possible?  What would I use to examine the IL? &lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt; 


Any better ideas out there? Comments? suggestions? 


----

**EDIT** - thinking about this further, compile-and-invoke is not acceptable, because the invoke may have side effects. So the first option must be ruled out. 

Also, I think I cannot assume the presence of .NET 4.0.  

----

**UPDATE** - The correct answer, unmentioned above, but gently pointed out by Eric Lippert, is to implement a full fidelity type inference system.  It;s the only way to reliably determine the type of a var at design time.  But, it&#39;s also not easy to do.  Because I suffer no illusions that I want to attempt to build such a thing, I took the shortcut of option 2  - extract the relevant declaration code, and compile it, then inspect the resulting IL.  

This actually works, for a fair subset of the completion scenarios. 

For example, suppose in the following code fragments, the ? is the position at which the user asks for completion.  This works: 

    var x = &quot;hello there&quot;; 
    x.?

The completion realizes that x is a String, and provides the appropriate options. It does this by generating and then compiling the following source code: 

    namespace N1 {
      static class dmriiann5he { // randomly-generated class name
        static void M1 () {
           var x = &quot;hello there&quot;; 
        }
      }
    }

...and then inspecting the IL with simple reflection.

This also works:

    var x = new XmlDocument();
    x.? 

The engine adds the appropriate using clauses to the generated source code, so that it compiles properly, and then the IL inspection is the same. 

This works, too:

    var x = &quot;hello&quot;; 
    var y = x.ToCharArray();    
    var z = y.?

It just means the IL inspection has to find the type of the third local variable, instead of the first.  

And this:

    var foo = &quot;Tra la la&quot;;
    var fred = new System.Collections.Generic.List&lt;String&gt;
        {
            foo,
            foo.Length.ToString()
        };
    var z = fred.Count;
    var x = z.?

...which is just one level deeper that the prior example. 

But, what *doesn&#39;t* work is completion on any local variable whose initialization depends at any point on an instance member, or local method argument. Like: 

    var foo = this.InstanceMethod();
    foo.?

Nor LINQ syntax.

I&#39;ll have to think about how valuable those things are before I consider addressing them via what is definitely a &quot;limited design&quot; (polite word for hack) for completion. 
 
An approach to addressing the issue with dependencies on method arguments or instance methods would be to replace, in the fragment of code that gets generated, compiled and then IL analyzed, the references to those things with &quot;synthetic&quot; local vars of the same type.  

----

**Another Update** - completion on vars that depend on instance members, now works.  

What I did was interrogate the type (via semantic), and then generate synthetic stand-in members for all existing members.  For a C# buffer like this: 

    public class CsharpCompletion
    {
        private static int PrivateStaticField1 = 17;

        string InstanceMethod1(int index)
        {
            ...lots of code here...
            return result;
        }

        public void Run(int count)
        {
            var foo = &quot;this is a string&quot;;
            var fred = new System.Collections.Generic.List&lt;String&gt;
            {
                foo,
                foo.Length.ToString()
            };
            var z = fred.Count;
            var mmm = count + z + CsharpCompletion.PrivateStaticField1;
            var nnn = this.InstanceMethod1(mmm);
            var fff = nnn.?

            ...more code here...

...the generated code that gets compiled, so that I can learn from the output IL the type of the local var nnn, looks like this: 

    namespace Nsbwhi0rdami {
      class CsharpCompletion {
        private static int PrivateStaticField1 = default(int);
        string InstanceMethod1(int index) { return default(string); }

        void M0zpstti30f4 (int count) {
           var foo = &quot;this is a string&quot;;
           var fred = new System.Collections.Generic.List&lt;String&gt; { foo, foo.Length.ToString() };
           var z = fred.Count;
           var mmm = count + z + CsharpCompletion.PrivateStaticField1;
           var nnn = this.InstanceMethod1(mmm);
          }
      }
    }


All of the instance and static type members are available in the skeleton code.  It compiles successfully.  At that point, determining the type of the local var is straightforward via Reflection. 

What makes this possible is:

 - the ability to run powershell in emacs
 - the C# compiler is really fast. On my machine, it takes about 0.5s to compile an in-memory assembly. Not fast enough for between-keystrokes analysis, but fast enough to support the on-demand generation of completion lists. 

I haven&#39;t looked into LINQ yet.   
That will be a much bigger problem because the semantic lexer/parser emacs has for C#, doesn&#39;t &quot;do&quot; LINQ. 


  [1]: http://blogs.msdn.com/powershell/archive/2008/04/15/powershell-running-inside-of-emacs.aspx

How can I reliably determine the type of a variable that is declared using var at design time?

I see some interesting discussions here about static vs. dynamic typing.
I generally prefer static typing, due to compile type checking, better documented code, etc. However, I do agree that they do clutter up the code if done the way Java does it, for example.

So I&#39;m about to start building a functional style language of my own, and type inference is one of the things that I want to implement. I do understand that it is a big subject, and I&#39;m not trying to create something that has not been done before, just basic inferencing...

Any pointers on what to read up that will help me with this? Preferably something more pragmatic/practical as opposed to more theoretical category theory/type theory texts. If there&#39;s an implementation discussion text out there, with data structures/algorithms, that would just be lovely.

implementing type inference

I am getting the following error when I try to find a `RecycleView` by id.

&gt;**Error:-** 
&gt;Type inference failed: Not enough information to infer parameter **T**

[![Error][1]][1]

Code:

    class FirstRecycleViewExample : AppCompatActivity() {
        val data = arrayListOf&lt;String&gt;()
        override fun onCreate(savedInstanceState: Bundle?) {
            super.onCreate(savedInstanceState)
            setContentView(R.layout.first_recycleview)
    
            val recycler_view =  findViewById(R.id.recycler_view) as RecyclerView ///IN THIS LINE I AM GETTING THE ERROR
    
            data.add(&quot;First Data&quot;)
            data.add(&quot;Second Data&quot;)
            data.add(&quot;Third Data&quot;)
            data.add(&quot;Forth Data&quot;)
            data.add(&quot;Fifth Data&quot;)
    
            //creating our adapter
            val adapter = CustomRecycleAdapter(data)
    
            //now adding the adapter to recyclerview
            recycler_view.adapter = adapter
        }
    }

  [1]: https://i.stack.imgur.com/cQLGp.png

Not able to &quot;findViewById&quot; in Kotlin. Getting error &quot;Type inference failed&quot;

A lot of blogs, and the [manual itself][1], say that Julia is [dynamically typed][2].
But from my reading of the manual, it sounds to me more like it is 
[statically typed][3] with [type inference][4], like [F#][5].

 - **Is Julia statically typed with type inference?**
 - **Is it dynamically typed?** 
 - I&#39;m assuming it is dynamically typed, it seems unlikely the manual is wrong.
 - **Is type inference involved in Julia at all?**


  [1]: https://docs.julialang.org/en/v1/manual/types/#man-types-1
  [2]: http://en.wikipedia.org/wiki/Type_system#Dynamic_type-checking_and_runtime_type_information
  [3]: http://en.wikipedia.org/wiki/Type_system#Static_type-checking
  [4]: http://en.wikipedia.org/wiki/Type_inference
  [5]: https://msdn.microsoft.com/en-us/library/dd233180.aspx

Is Julia dynamically typed?

While writing code for another answer on this site I came across this peculiarity:

    static void testSneaky() {
      final Exception e = new Exception();
      sneakyThrow(e);    //no problems here
      nonSneakyThrow(e); //ERRROR: Unhandled exception: java.lang.Exception
    }
  
    @SuppressWarnings(&quot;unchecked&quot;)
    static &lt;T extends Throwable&gt; void sneakyThrow(Throwable t) throws T {
      throw (T) t;
    }
  
    static &lt;T extends Throwable&gt; void nonSneakyThrow(T t) throws T {
      throw t;
    }

First, I am quite confused why the `sneakyThrow` call is OK to the compiler. What possible type did it infer for `T` when there is no mention anywhere of an unchecked exception type?

Second, accepting that this works, why then does the compiler complain on the `nonSneakyThrow` call? They seem very much alike.

A peculiar feature of exception type inference in Java 8

I am new to Haskell and facing a &quot;cannot construct infinite type&quot; error that I cannot make sense of. 

In fact, beyond that, I have not been able to find a good explanation of what this error even means, so if you could go beyond my basic question and explain the &quot;infinite type&quot; error, I&#39;d really appreciate it.

Here&#39;s the code: 

    intersperse :: a -&gt; [[a]] -&gt; [a]
    
    -- intersperse &#39;*&#39; [&quot;foo&quot;,&quot;bar&quot;,&quot;baz&quot;,&quot;quux&quot;] 
    --  should produce the following:
    --  &quot;foo*bar*baz*quux&quot;
    
    -- intersperse -99 [ [1,2,3],[4,5,6],[7,8,9]]
    --  should produce the following:
    --  [1,2,3,-99,4,5,6,-99,7,8,9]
    
    intersperse _ [] = []
    intersperse _ [x] = x
    intersperse s (x:y:xs) = x:s:y:intersperse s xs

And here&#39;s the error trying to load it into the interpreter: 

    Prelude&gt; :load ./chapter.3.ending.real.world.haskell.exercises.hs
    [1 of 1] Compiling Main (chapter.3.ending.real.world.haskell.exercises.hs, interpreted )

    chapter.3.ending.real.world.haskell.exercises.hs:147:0:
    Occurs check: cannot construct the infinite type: a = [a]
    When generalising the type(s) for `intersperse&#39;
    Failed, modules loaded: none.

Thanks.

--

Here is some corrected the code and a general guideline for dealing with the &quot;infinite type&quot; error in Haskell:

**Corrected code**

    intersperse _ [] = []
    intersperse _ [x] = x
    intersperse s (x:xs) =  x ++ s:intersperse s xs 

**What the problem was:**

My type signature states that the second parameter to intersperse is a *list of lists*. Therefore, when I pattern matched against &quot;s (x:y:xs)&quot;, x and y became **lists**. And yet I was treating x and y as elements, not lists. 

**Guideline for dealing with the &quot;infinite type&quot; error:**

*Most of the time, when you get this error, you have forgotten the types of the various variables you&#39;re dealing with, and you have attempted to use a variable as if it were some other type than what it is. Look carefully at what type everything is versus how you&#39;re using it, and this will usually uncover the problem.*






Why does this Haskell code produce the &quot;infinite type&quot; error?

I&#39;m having lots of Funcy fun (fun intended) with generic methods. In most cases C# type inference is smart enough to find out what generic arguments it must use on my generic methods, but now I&#39;ve got a design where the C# compiler doesn&#39;t succeed, while I believe it could have succeeded in finding the correct types.

Can anyone tell me whether the compiler is a bit dumb in this case, or is there a very clear reason why it can&#39;t infer my generic arguments?

Here&#39;s the code:

Classes and interface definitions:

    interface IQuery&lt;TResult&gt; { }

    interface IQueryProcessor
    {
        TResult Process&lt;TQuery, TResult&gt;(TQuery query)
            where TQuery : IQuery&lt;TResult&gt;;
    }

    class SomeQuery : IQuery&lt;string&gt;
    {
    }

Some code that does not compile:

    class Test
    {
        void Test(IQueryProcessor p)
        {
            var query = new SomeQuery();

            // Does not compile :-(
            p.Process(query);

            // Must explicitly write all arguments
            p.Process&lt;SomeQuery, string&gt;(query);
        }
    }

Why is this? What am I missing here?

Here&#39;s the compiler error message (it doesn&#39;t leave much to our imagination):

&gt; The type arguments for method IQueryProcessor.Process&lt;TQuery,
&gt; TResult&gt;(TQuery) cannot be inferred from the usage. Try specifying the
&gt; type arguments explicitly.

The reason I believe C# should be able to infer it is because of the following:

 1. I supply an object that implements `IQuery&lt;TResult&gt;`.
 2. That only `IQuery&lt;TResult&gt;` version that type implements is `IQuery&lt;string&gt;` and thus TResult must be `string`.
 3. With this information the compiler has TResult and TQuery.

Why doesn&#39;t C# infer my generic types?

I&#39;m puzzled by how the haskell compiler sometimes infers types that are less
polymorphic than what I&#39;d expect, for example when using point-free definitions.

It seems like the issue is the &quot;monomorphism restriction&quot;, which is on by default on
older versions of the compiler.

Consider the following haskell program:

    {-# LANGUAGE MonomorphismRestriction #-}

    import Data.List(sortBy)

    plus = (+)
    plus&#39; x = (+ x)

    sort = sortBy compare

    main = do
      print $ plus&#39; 1.0 2.0
      print $ plus 1.0 2.0
      print $ sort [3, 1, 2]


If I compile this with `ghc` I obtain no erros and the output of the executable is:

    3.0
    3.0
    [1,2,3]

If I change the `main` body to:

    main = do
      print $ plus&#39; 1.0 2.0
      print $ plus (1 :: Int) 2
      print $ sort [3, 1, 2]

I get no compile time errors and the output becomes:

    3.0
    3
    [1,2,3]

as expected. However if I try to change it to:

    main = do
      print $ plus&#39; 1.0 2.0
      print $ plus (1 :: Int) 2
      print $ plus 1.0 2.0
      print $ sort [3, 1, 2]

I get a type error:

&lt;!-- language: lang-none --&gt;

    test.hs:13:16:
        No instance for (Fractional Int) arising from the literal ‘1.0’
        In the first argument of ‘plus’, namely ‘1.0’
        In the second argument of ‘($)’, namely ‘plus 1.0 2.0’
        In a stmt of a &#39;do&#39; block: print $ plus 1.0 2.0

The same happens when trying to call `sort` twice with different types:

    main = do
      print $ plus&#39; 1.0 2.0
      print $ plus 1.0 2.0
      print $ sort [3, 1, 2]
      print $ sort &quot;cba&quot;

produces the following error:

&lt;!-- language: lang-none --&gt;

    test.hs:14:17:
        No instance for (Num Char) arising from the literal ‘3’
        In the expression: 3
        In the first argument of ‘sort’, namely ‘[3, 1, 2]’
        In the second argument of ‘($)’, namely ‘sort [3, 1, 2]’


 - Why does `ghc` suddenly think that `plus` isn&#39;t polymorphic and requires an `Int` argument?
   The only reference to `Int` is in *an application* of `plus`, how can that matter
   when the definition is clearly polymorphic?
 - Why does `ghc` suddenly think that `sort` requires a `Num Char` instance?

Moreover if I try to place the function definitions into their own module, as in:

    {-# LANGUAGE MonomorphismRestriction #-}

    module TestMono where

    import Data.List(sortBy)

    plus = (+)
    plus&#39; x = (+ x)

    sort = sortBy compare

I get the following error when compiling:

&lt;!-- language: lang-none --&gt;

    TestMono.hs:10:15:
        No instance for (Ord a0) arising from a use of ‘compare’
        The type variable ‘a0’ is ambiguous
        Relevant bindings include
          sort :: [a0] -&gt; [a0] (bound at TestMono.hs:10:1)
        Note: there are several potential instances:
          instance Integral a =&gt; Ord (GHC.Real.Ratio a)
            -- Defined in ‘GHC.Real’
          instance Ord () -- Defined in ‘GHC.Classes’
          instance (Ord a, Ord b) =&gt; Ord (a, b) -- Defined in ‘GHC.Classes’
          ...plus 23 others
        In the first argument of ‘sortBy’, namely ‘compare’
        In the expression: sortBy compare
        In an equation for ‘sort’: sort = sortBy compare

 - Why isn&#39;t `ghc` able to use the polymorphic type `Ord a =&gt; [a] -&gt; [a]` for `sort`?
 - And why does `ghc` treat `plus` and `plus&#39;` differently? `plus` should have the
  polymorphic type `Num a =&gt; a -&gt; a -&gt; a` and I don&#39;t really see how this is different
  from the type of `sort` and yet only `sort` raises an error.

Last thing: if I comment the definition of `sort` the file compiles. However
if I try to load it into `ghci` and check the types I get:

&lt;!-- language: lang-none --&gt;

    *TestMono&gt; :t plus
    plus :: Integer -&gt; Integer -&gt; Integer
    *TestMono&gt; :t plus&#39;
    plus&#39; :: Num a =&gt; a -&gt; a -&gt; a

Why isn&#39;t the type for `plus` polymorphic?


----

&lt;sup&gt;
This is the canonical question about monomorphism restriction in Haskell
as discussed in [the meta question](https://meta.stackoverflow.com/questions/294053/can-we-provide-a-canonical-questionanswer-for-haskells-monomorphism-restrictio).
&lt;/sup&gt;

What is the monomorphism restriction?

Why did the Typescript folks create the `infer` keyword?
According to the [documents][1], this is an example of how you would use it:

    type ReturnType&lt;T&gt; = T extends (...args: any[]) =&gt; infer R ? R : any;

I don&#39;t understand why this is needed. Why can&#39;t it just be:

    type ReturnType&lt;T&gt; = T extends (...args: any[]) =&gt; R ? R : any;


Why doesn&#39;t this work? Why is the `infer` keyword necessary ?
  [1]: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html

Why is the infer keyword needed in Typescript?

Maybe I&#39;m overworked, but this isn&#39;t compiling (CS0411). Why?

    interface ISignatur&lt;T&gt;
    {
        Type Type { get; }
    }
    
    interface IAccess&lt;S, T&gt; where S : ISignatur&lt;T&gt;
    {
        S Signature { get; }    
        T Value { get; set; }
    }
    
    class Signatur : ISignatur&lt;bool&gt;
    {
        public Type Type
        {
            get { return typeof(bool); }
        }
    }
    
    class ServiceGate
    {
        public IAccess&lt;S, T&gt; Get&lt;S, T&gt;(S sig) where S : ISignatur&lt;T&gt;
        {
            throw new NotImplementedException();
        }
    }
    
    static class Test
    {
        static void Main()
        {
            ServiceGate service = new ServiceGate();
            var access = service.Get(new Signatur()); // CS4011 error
        }
    }

Anyone an idea why not? Or how to solve?

The type arguments for method cannot be inferred from the usage

This program compiles fine in Java 7 (or in Java 8 with `-source 7`), but fails to compile with Java 8:

    interface Iface&lt;T&gt; {}
    class Impl implements Iface&lt;Impl&gt; {}
    
    class Acceptor&lt;T extends Iface&lt;T&gt;&gt; {
        public Acceptor(T obj) {}
    }
    
    public class Main {
        public static void main(String[] args) {
            Acceptor&lt;?&gt; acceptor = new Acceptor&lt;&gt;(new Impl());
        }
    }

Result:

    Main.java:10: error: incompatible types: cannot infer type arguments for Acceptor&lt;&gt;
            Acceptor&lt;?&gt; acceptor = new Acceptor&lt;&gt;(new Impl());
                                               ^
        reason: inference variable T has incompatible bounds
          equality constraints: Impl
          upper bounds: Iface&lt;CAP#1&gt;,Iface&lt;T&gt;
      where T is a type-variable:
        T extends Iface&lt;T&gt; declared in class Acceptor
      where CAP#1 is a fresh type-variable:
        CAP#1 extends Iface&lt;CAP#1&gt; from capture of ?
    1 error

In other words, this is a _backwards_ source incompatibility between Java 7 and 8. I&#39;ve gone through [Incompatibilities between Java SE 8 and Java SE 7](http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198) list but did not found anything that would fit my problem.

So, is this a bug?

Environment:

    $ /usr/lib/jvm/java-8-oracle/bin/java -version
    java version &quot;1.8.0&quot;
    Java(TM) SE Runtime Environment (build 1.8.0-b132)
    Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)

Why does this Java 8 program not compile?

The F# compiler appears to perform type inference in a (fairly) strict top-to-bottom, left-to-right fashion. This means you must do things like put all definitions before their use, order of file compilation is significant, and you tend to need to rearrange stuff (via `|&gt;` or what have you) to avoid having explicit type annotations.

How hard is it to make this more flexible, and is that planned for a future version of F#? Obviously it can be done, since Haskell (for example) has no such limitations with equally powerful inference. Is there anything inherently different about the design or ideology of F# that is causing this?

Why is F#&#39;s type inference so fickle?

I would like to understand the key difference between parametric polymorphism such as polymorphism of generic classes/functions in the Java/Scala/C++ languages and &quot;ad-hoc&quot; polymorphism in the Haskell type system. I&#39;m familiar with the first kind of languages, but I have never worked with the Haskell.

More precisely:

 1. How is type inference algorithm e.g. in Java different from the type inference in Haskell?
 2. Please, give me an example of the situation where something can be written in Java/Scala but can not be written in Haskell(according to the modular features of these platforms too), and vice-versa.

Thanks in advance.

Parametric polymorphism vs Ad-hoc polymorphism

As I understand it, both `decltype` and `auto` will attempt to figure out what the type of something is.

If we define:

    int foo () {
    	return 34;
    }

Then both declarations are legal:

	auto x = foo();
	cout &lt;&lt; x &lt;&lt; endl;
	
	decltype(foo()) y = 13;
	cout &lt;&lt; y &lt;&lt; endl;

Could you please tell me what the main difference between `decltype` and `auto` is?

decltype vs auto

The **[C# language specification](http://www.microsoft.com/downloads/en/details.aspx?familyid=DFBF523C-F98C-4804-AFBD-459E846B268E&amp;displaylang=en)** describes type inference in Section &#167;7.5.2. There is a detail in it that I don’t understand. Consider the following case:

    // declaration
    void Method&lt;T&gt;(T obj, Func&lt;string, T&gt; func);

    // call
    Method(&quot;obj&quot;, s =&gt; (object) s);

Both the Microsoft and Mono C# compilers correctly infer `T` = `object`, but my understanding of the algorithm in the specification would yield `T` = `string` and then fail. Here is how I understand it:

**The first phase**

* If Ei is an anonymous function, an *explicit parameter type inference* (&#167;7.5.2.7) is made from Ei to Ti

    ⇒ has no effect, because the lambda expression has no explicit parameter types. Right?

* Otherwise, if Ei has a type U and xi is a value parameter then a *lower-bound inference* is made from U to Ti.

    ⇒ the first parameter is of static type `string`, so this adds `string` to the lower bounds for `T`, right?

**The second phase**

* All *unfixed* type variables Xi which do not *depend on* (&#167;7.5.2.5) any Xj are fixed (&#167;7.5.2.10).

    ⇒ `T` is unfixed; `T` doesn’t depend on anything... so `T` should be fixed, right?

**&#167;7.5.2.11 Fixing**

* The set of candidate types Uj starts out as the set of all types in the set of bounds for Xi.

    ⇒ { `string` (lower bound) }

* We then examine each bound for Xi in turn: [...] For each lower bound U of Xi all types Uj to which there is not an implicit conversion from U are removed from the candidate set. [...]

    ⇒ doesn’t remove anything from the candidate set, right?

* If among the remaining candidate types Uj there is a unique type V from which there is an implicit conversion to all the other candidate types, then Xi is fixed to V.

    ⇒ Since there is only one candidate type, this is vacuously true, so Xi is fixed to `string`. Right?

- - -

**So where am I going wrong?**

Problem understanding C# type inference as described in the language specification

The following code surprisingly is compiling successfully:

    Consumer&lt;String&gt; p = &quot;&quot;::equals;
This too:

    p = s -&gt; &quot;&quot;.equals(s);
But this is fails with the error `boolean cannot be converted to void` as expected:

    p = s -&gt; true;

Modification of the second example with parenthesis also fails:

    p = s -&gt; (&quot;&quot;.equals(s));

Is it a bug in Java compiler or is there a type inference rule I don&#39;t know about?

Why do Consumers accept lambdas with statement bodies but not expression bodies?

**Code** (spring-web 5.1.2)

    public static void main(String[] args) {
        RestTemplate restTemplate = new RestTemplate();

        HttpHeaders headers = new HttpHeaders();
        headers.set(HttpHeaders.AUTHORIZATION, &quot;token&quot;);
        HttpEntity&lt;Object&gt; requestEntity = new HttpEntity&lt;&gt;(headers);

        ResponseEntity&lt;Object&gt; test = restTemplate.exchange(
                &quot;https://example.com&quot;,
                HttpMethod.GET,
                new HttpEntity&lt;&gt;(headers),
                new ParameterizedTypeReference&lt;&gt;() { // fails here
                });
    }

**OracleJDK 1.8** (expected output)

&gt; cannot infer type arguments for
&gt; org.springframework.core.ParameterizedTypeReference&lt;T&gt; 

&gt; reason: cannot use &#39;&lt;&gt;&#39; with anonymous inner classes

**OracleJDK 11.0.2** (not expected output)

&gt; compiler message file broken: key=compiler.misc.msg.bug
&gt; arguments=11.0.2, {1}, {2}, {3}, {4}, {5}, {6}, {7}
&gt; java.lang.NullPointerException 	at
&gt; jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply(Flow.java:1235)
&gt; 	at
&gt; jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634)
&gt; 	at
&gt; jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
&gt; 	at
&gt; jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398)
&gt; 	at
&gt; jdk.compiler/com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitVarDef(Flow.java:989) &lt;br/&gt;
&gt; ...

If I change diamond operator to explicit type

 `new ParameterizedTypeReference&lt;&gt;(){}` to `new ParameterizedTypeReference&lt;Object&gt;(){}`

then the code compiles successfully on both JDKs.

Is it a known compiler bug?

JDK 11.0.2 compilation fails with javac NPE on anonymous parameterized class type inference

Given:

    static TDest Gimme&lt;TSource,TDest&gt;(TSource source) 
    { 
        return default(TDest); 
    }

Why can&#39;t I do:

    string dest = Gimme(5);

without getting the compiler error:

`error CS0411: The type arguments for method &#39;Whatever.Gimme&lt;TSource,TDest&gt;(TSource)&#39; cannot be inferred from the usage. Try specifying the type arguments explicitly.`

The `5` can be inferred as `int`, but there&#39;s a restriction where the compiler won&#39;t/can&#39;t resolve the return type as a `string`.  I&#39;ve read in several places that *this is by design* but no real explanation.  I read somewhere that this might change in C# 4, but it hasn&#39;t.

Anyone know why return types cannot be inferred from generic methods?  Is this one of those questions where the answer&#39;s so obvious it&#39;s staring you in the face?  I hope not!

Generic methods in .NET cannot have their return types inferred. Why?

I had been programming under the assumption that, when calling a method in C# 4.0, supplying names for your arguments would not affect the outcome unless in doing so you were &quot;skipping&quot; one or more optional parameters.

So I was a bit surprised to discover the following behavior:

Given a method which takes a `Func&lt;T&gt;`, executes it and returns the result:

    public static T F&lt;T&gt;(Func&lt;T&gt; f)
    {
        return f();
    }

And another method from which the above method is visible:

    static void Main()
    {
        string s;

calling F (without named arguments) compiles without any issues:

        s = F&lt;string&gt;(() =&gt; &quot;hello world&quot;); // with explicit type argument &lt;string&gt;
        s = F(() =&gt; &quot;hello world&quot;); // with type inference

And when using a named argument...

        s = F&lt;string&gt;(f: () =&gt; &quot;hello world&quot;);

... the above line of code using the explicit type argument still compiles without issues. And maybe not too surprisingly, if you have ReSharper installed it will suggest that the &quot;Type argument specification is redundant&quot;.

However, when removing the type argument...

        s = F(f: () =&gt; &quot;hello world&quot;);

the C# compiler will report this error:

&gt;The type arguments for method &#39;Program.F&lt;T&gt;(System.Func&lt;T&gt;)&#39; cannot be inferred from the usage. Try specifying the type arguments explicitly.

Is there a logical explanation for this interaction between named arguments and type inference?

Is this behavior documented somewhere in the language specification?

I understand that it is not necessary at all for me to name the argument. However, I discovered this behavior in a much more complex scenario where I thought it might make sense to name the arguments in my method call for internal documentation purposes. I am not asking how to work around this issue. I am trying to understand some of the finer points of the language.

To make things more interesting I discovered that the following all compiles without issues:

        Func&lt;string&gt; func = () =&gt; &quot;hello world&quot;;
        s = F&lt;string&gt;(func);
        s = F(func);
        s = F&lt;string&gt;(f: func);
        s = F(f: func);
    }

By the way I have observed the same behavior with non-static methods. I just chose to use static methods to make the example here a bit shorter.

Named arguments and generic type inference in C# 4.0

In VS2012, you can hover over a typescript variable and it will show you the inferred type. Is there a similar feature in webstorm?

How to show inferred TypeScript type in WebStorm?

So, I have a class with a constructor like this:

    public FilterList(Set&lt;Integer&gt; labels) {
        ...
    }

and I want to construct a new `FilterList` object with an empty set. Following Joshua Bloch&#39;s advice in his book Effective Java, I don&#39;t want to create a new object for the empty set; I&#39;ll just use `Collections.emptySet()` instead:

    FilterList emptyList = new FilterList(Collections.emptySet());

This gives me an error, complaining that `java.util.Set&lt;java.lang.Object&gt;` is not a `java.util.Set&lt;java.lang.Integer&gt;`. OK, how about this:

    FilterList emptyList = new FilterList((Set&lt;Integer&gt;)Collections.emptySet());

This also gives me an error! Ok, how about this:

    Set&lt;Integer&gt; empty = Collections.emptySet();
    FilterList emptyList = new FilterList(empty);

Hey, it works! But why? After all, Java doesn&#39;t have type inference, which is why you get an unchecked conversion warning if you do `Set&lt;Integer&gt; foo = new TreeSet()` instead of `Set&lt;Integer&gt; foo = new TreeSet&lt;Integer&gt;()`. But `Set&lt;Integer&gt; empty = Collections.emptySet();` works without even a warning. Why is that?

Why does using Collections.emptySet() with generics work in assignment but not as a method parameter?

I am trying to learn Scala now, with a little bit of experience in Haskell. One thing that stood out as odd to me is that all function parameters in Scala *must* be annotated with a type - something that Haskell does not require. Why is this? To try to put it as a more concrete example: an add function is written like this:

    def add(x:Double, y:Double) = x + y

But, this only works for doubles(well, ints work too because of the implicit type conversion). But what if you want to define your own type that defines its own *+* operator. How would you write an add function which works for any type that defines a *+* operator?

Scala: How to define &quot;generic&quot; function parameters?

I don&#39;t understand the last line of the example on page 148 of the FCD (&#167;7.6.1.2/4):

    const int&amp;&amp; foo();
    int i;
    struct A { double x; };
    const A* a = new A();
    decltype(foo()) x1 = i;     // type is const int&amp;&amp;
    decltype(i) x2;             // type is int
    decltype(a-&gt;x) x3;          // type is double
    decltype((a-&gt;x)) x4 = x3;   // type is const double&amp;

Why do the parentheses make a difference here? Shouldn&#39;t it simply be `double` like in the line above?

decltype and parentheses

In C#, the following type-inference works:

    var s = &quot;abcd&quot;;

But why can&#39;t the type be inferred when the variable is a constant?

The following throws a compile-time exception:

    const var s = &quot;abcd&quot;; // &lt;= Compile time error: 
                          //    Implicitly-typed local variables cannot be constant



Type-inferring a constant in C#

Given a typeclass where instance selection should be performed based on the return type:

    case class Monoid[A](m0: A) // We only care about the zero here
    implicit def s[T] : Monoid[Set[T]] = Monoid(Set.empty[T])
    implicit def l[T] : Monoid[List[T]] = Monoid(List.empty[T])
    def mzero[A](implicit m: Monoid[A]) : A = m.m0

why does Scala (2.11.6) fail to resolve the proper instance:

    scala&gt; mzero : List[Int]
    &lt;console&gt;:24: error: ambiguous implicit values:
     both method s of type [T]=&gt; Monoid[Set[T]]
     and method l of type [T]=&gt; Monoid[List[T]]
     match expected type Monoid[A]
                  mzero : List[Int]
                  ^

when it has no problems finding an implicit based on the return type when using the **implicitly** function (we redefine it here as **i** to illustrate how similar it is to **mzero**)

    def i[A](implicit a : A) : A = a
    scala&gt; i : Monoid[List[Int]]
    res18: Monoid[List[Int]] = Monoid(List())

The `Monoid[A]`, instead of `Monoid[List[Int]]` in the error message is puzzling.

I would assume many scalaz contributors to be familiar with this problem as it seems to limit the convenience of typeclasses in scala.

EDIT: I&#39;m looking into getting this working without forgoing type inference. Otherwise I&#39;d like understand why that&#39;s not possible. If this limitation is documented as a Scala issue, I could not find it.

Unexpected implicit resolution based on inference from return type

I have a `DataFrame` with two columns: a column of `int` and a column of `str`. 

 - I understand that if I insert `NaN` into the `int` column, Pandas will convert all the `int` into `float` because there is no `NaN` value for an `int`.
 - However, when I insert `None` into the `str` column, Pandas converts all my `int` to `float` as well. This doesn&#39;t make sense to me - why does the value I put in column 2 affect column 1?

Here&#39;s a simple working example):

    import pandas as pd
    df = pd.DataFrame()
    df[&quot;int&quot;] = pd.Series([], dtype=int)
    df[&quot;str&quot;] = pd.Series([], dtype=str)

    df.loc[0] = [0, &quot;zero&quot;]
    print(df)
    print()

    df.loc[1] = [1, None]
    print(df)

The output is:

       int   str
    0    0  zero
    
       int   str
    0  0.0  zero
    1  1.0   NaN

Is there any way to make the output the following:

       int   str
    0    0  zero
    
       int   str
    0    0  zero
    1    1   NaN

without recasting the first column to `int`.

 - I prefer using `int` instead of `float` because the actual data in
   that column are integers. If there&#39;s not workaround, I&#39;ll just
   use `float` though.
   
 - I prefer not having to recast because in my actual code, I don&#39;t   
   store the actual `dtype`.

 - I also need the data inserted row-by-row.

All Type Inference Solutions on Gang of Coders

Total of 36 Type Inference Solutions