Overloading based on attributes - is it a good idea?

[Jonathan Marler]

On Tuesday, 28 May 2019 at 21:41:28 UTC, Walter Bright wrote:
> On 5/28/2019 2:12 PM, Jonathan Marler wrote:
>> turtles all the way down.
>
> Again, it is not that simple. Call graphs have cycles in them, 
> they are not acyclic. Furthermore, since you suggested 
> different code be instantiated based on inferred attributes, 
> you have a FAR FAR more complex problem to resolve, since the 
> graph connections change at every decision point.

Again, in this case it is that simple. I'll explain it another 
way, maybe it will make sense this time.

Attributes on functions inside template are inferred bottom-up, 
but templates are instantiated top-down.  So trying to use 
inferred attributes to affect template instances is going to get 
you into a cyclic mess.  In this case you are absolutely right.

What I was suggesting is that you propagate the state as to 
whether or not the GC is allowed top-down, the same way templates 
are instantiated.  You could do this today with template 
parameters, but like I said, it's not scalable because it 
requires every single template to add this parameter.  It works 
because you are propagating this state in the same direction as 
you are instantiating the templates, top down, so you know before 
you even see the inside of the template whether or not the GC is 
allowed.

So the argument that this creates a complex cyclic dependency 
resolution problem is not correct in the example I showed.  
However, there are other arguments against it, the main one I see 
being that you would essentially need to add "implicit template 
parameters". This would be a big change to the language with alot 
of consequences, something that would most certainly require a 
DIP and alot of research and thought, but, you shouldn't 
immediately dismiss and idea with "Hell No", especially when you 
don't fully understand it.