Overloading based on attributes - is it a good idea?

[Jonathan Marler]

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

Unfortunately my mathematical emphasis was on number theory and 
combinatorics...and it was only a bachelors :)

But after sending my initial response I realized that if my 
example functions were also templates, then they would also have 
to use the allowGC = __traits(callSiteCompiles, new Object).  In 
fact, in order to propogate the information, every template 
function that could eventually call one of these allowGC 
templates would also need to add the allowGC parameter to their 
template parameter list.  Completely unscalable.

That being said, even though the solution is unscalable and 
verbose, it does actually work.  The compiler today is able to 
infer these attributes as demonstrated by the first version in my 
example code I showed earlier.  And it will also work no matter 
how deep the rabit hole goes...turtles all the way down.

It works because it determines the GC requirement top-down 
starting from the first non-template.  Since non-templates do not 
infer the @nogc attribute, the compiler already knows the answer 
to this inside each function that isn't a template.  So we just 
need a way to propagate that information to each template 
instantiated inside that function which is what the template 
parameter allowGC did.  We know this solution doesn't scale when 
using template parameters, but it would work if the compiler kept 
track of this internally.  You'd just need to add a boolean 
variable to each template instance that indicates whether the 
caller allowed the GC or not, that is passed in when the template 
is instantiated.

Anyway, I'm not saying we should do it, or even that we should do 
it this way, just saying it could be done.  The math here is 
actually pretty simple, no need for a PhD this time.