[nem-bug] [Nemerle 0000441]: problems with constraints put too early on overloads

[feedback at nemerle.org]

The following issue has been RESOLVED.
======================================================================
<http://nemerle.org/bugs/view.php?id=441> 
======================================================================
Reported By:                phiho
Assigned To:                malekith
======================================================================
Project:                    Nemerle
Issue ID:                   441
Category:                   Compiler
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     resolved
Resolution:                 fixed
Fixed in Version:           
======================================================================
Date Submitted:             05-04-2005 19:41 CEST
Last Modified:              12-19-2006 16:52 CET
======================================================================
Summary:                    problems with constraints put too early on overloads
Description: 
using System ;

class MuchHarderInference
{
   static Main() : void
  {
    def f(x)
    {
       x.Length ;
    }

// Version 1 is OK, not so hard ;-)
// Console.WriteLine ("{0} has {1} characters", "foo", f("foo")) ;   //
(1)

// Why version (2) is MuchHarder - Errors below
  Console.WriteLine ("foo has {0} characters", f("foo")) ;      // (2)
 }
}


======================================================================

----------------------------------------------------------------------
 malekith - 05-24-05 19:12 
----------------------------------------------------------------------
The problem is not really related to overload selection rules. The rules
are good, the problem is that they are applied too early.

In the example above, during overload selection for Console.WriteLine we
don't yet know the type of f("foo"). Therefore (string,object),
(string,params array[object]) and (string,array[object]) match. Now we
select the best overload. We throw away (string,object) overload, because
(string,array[object]) is more specific. Later we throw away params
overload, because there is a non-parms overload.

This way the return type of f("foo") is constrained to be array[object]
which happens not to be true.

The way of dealing with it is to delay overload resolution of such
uncertain cases. However the definition of a ,,uncertain case'' ain't no
easy. Appling this rule for all calls with more than one matching overload
is done in the attached patch, but it breaks compilation of narray.n and
probably it would break in other places too.

Needs more consideration :/

----------------------------------------------------------------------
 malekith - 12-19-06 16:52 
----------------------------------------------------------------------
It is now resolved on trunk, seems like http://nemerle.org/bugs/view.php?id=770
was a duplicate of this one.
r7120

Issue History
Date Modified  Username       Field                    Change              
======================================================================
05-04-05 19:41 phiho          New Issue                                    
05-15-05 22:49 malekith       Relationship added       related to 0000410  
05-24-05 19:07 malekith       File Added: early-try.patch                    
05-24-05 19:07 malekith       Relationship deleted     related to 0000410  
05-24-05 19:12 malekith       Note Added: 0000815                          
05-24-05 19:12 malekith       Status                   new => confirmed    
05-24-05 19:12 malekith       Description Updated                          
05-24-05 19:12 malekith       Additional Information Updated                    
08-24-05 11:24 malekith       Summary                  Type inference bug =>
problems with constraints put too early on overloads
08-24-05 11:24 malekith       Description Updated                          
08-24-05 11:24 malekith       Additional Information Updated                    
12-19-06 16:52 malekith       Status                   confirmed => resolved
12-19-06 16:52 malekith       Resolution               open => fixed       
12-19-06 16:52 malekith       Assigned To               => malekith        
12-19-06 16:52 malekith       Note Added: 0001587                          
======================================================================