Overloading based on attributes - is it a good idea?

[aliak]

On Tuesday, 28 May 2019 at 20:26:50 UTC, Walter Bright wrote:
> On 5/28/2019 12:49 PM, Jonathan Marler wrote:
>> You're right it's undecidable inside the function, but I think 
>> it's decidable if you check it at the call site.
>
> Yet the call site may also be doing attribute inference.
>
> Think of a graph with nodes in it, all interconnected with 
> arbitrary edges, including cycles, and you have to find a set 
> of attributes that satisfy each of the edges in it, when adding 
> any attribute changes the topology of the graph.
>
> Even if there is an algorithm which can solve this, and I don't 
> have a PhD in graph theory and have no idea if there is one or 
> not:

http://dev.stephendiehl.com/fun/006_hindley_milner.html ? And the 
so called Algorithm W. I'm nowhere close to understanding how it 
seems to work though.

Swift uses an altered version: 
https://github.com/apple/swift/blob/master/docs/TypeChecker.rst

I assume the solver magic is in here: 
https://github.com/apple/swift/blob/master/lib/Sema/CSSolver.cpp

Rust used to use it but changed: 
http://smallcultfollowing.com/babysteps/blog/2014/07/09/an-experimental-new-type-inference-scheme-for-rust/

Though rust treats functions with different return types as the 
same definition and gives you an error.

The thing you said about overloading on return types made me go 
and check around a bit. I already knew that swift does this at 
least. So I guess it isn't ambiguous since it's been implemented. 
But maybe it has something to do with the type system 
implementation they use?

Cheers,
- Ali

>
> 1. there may be N solutions - which one is picked?
> 2. how do you explain to the user why?
> 3. how do you explain to the user when N is zero?
> 4. the combinatorics of this may mean it takes essentially 
> infinite time
> 5. I have a hard enough time implementing/debugging the current 
> bottom-up method
> 6. I've spent years dealing with problems with forward 
> references, when there are cycles in the reference graph and 
> incomplete types. Your proposal makes that infinitely worse.
>
> Like I said, it looks workable for trivial boundary cases, but 
> that isn't how things work when people start using such a 
> feature.
>
> So, no. Hell no :-)