> On Apr 29, 2015, at 6:19 PM, Stefan Karpinski <[email protected]> wrote: > > On Wed, Apr 29, 2015 at 6:07 PM, Scott Jones <[email protected] > <mailto:[email protected]>> wrote: > > I think this is easier to solve than you think. > The compiler should see this call as having a signature of Union(F,B), which > *neither* Foo.f nor Bar.f have... > > What does this mean? >
Maybe I’m misunderstanding the way the compiler is working… I thought it figured out the signature of the call, first with the most specific types for each argument, and then tried to find the method that matched that signature… > So, it can either, give an error, > > What error? Why? You want a feature which, when used, is an error? Why have > the feature in the first place then? If the compiler can’t figure out which one it is, then it *could* give an error… (and at compile time, not run-time)… Why should the case that really matters be prohibited, i.e.: f(Foo.F()) f(Bar.B()) or, more realistically: myRec = fetch(mySQLtable,rowId) myGlo = fetch(myMNode,subscript) The two things are totally independent… they are not generic functions, these are two totally separate APIs. They are unambiguous, and the intent is clear to the programmer. Your restrictions are making it very hard to develop easy to use APIs that make sense for the people using them… That’s why so many people have been bringing this issue up… > or be even smarter, and see that it should be equivalent to: > rand(Bool) ? f(Foo.F()) : f(Bar.B()), > which is *totally* determined statically! > > That trick happens to work in this particular example, but you can easily > construct cases where that transformation can't be done. If the argument to f > is a function argument, for example. But it still has the exact same problem. You can *construct* cases… however, in the interest of general programming utility, why can’t there be some way to let programmers have some isolation, while still being able to make best use of multiple dispatch? Having to decorate everything with the module name does not seem to fit in with using multiple dispatch… Scott > > What's the real problem here? > > Function merging has these problems: > It complects name resolution with dispatch – they are no longer orthogonal. > It makes all bindings from `using` semantically ambiguous – you have no idea > what a name means without actually doing a call.
