Overloading based on attributes - is it a good idea?
Jonathan Marler
johnnymarler at gmail.com
Tue May 28 21:59:01 UTC 2019
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.
More information about the Digitalmars-d
mailing list