Overloading based on attributes - is it a good idea?

[Walter Bright]

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:

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 :-)