On Monday, 23 April 2018 at 10:57:59 UTC, Simen Kjærås wrote:
There is no official definition. That's because some natural
rewrite rules are implied, which are very general, I assume...
How official do you want it to be? That's the only definition
in common use by others in the context of compilers.
Stating the existence of rewriting rules is a complex thing. They
is no place in the docu (which I could find until now) where they
are defined. Therefore, I rely on something which is common.
https://en.wikipedia.org/wiki/Natural_transformation
We can discuss, whether a template is a functor, but I think this
would go beyond the scope of this thread.
You mentioned a limited set of lowerings, defined by the
language. Where can I find them? I'm very interested in that.
There is no template rewriting taking place in the language
today - that seems to be a feature you are arguing for.
Semantic rewriting is not something which one can take control
of. Either you have semantically equal constructs or not.
getOverloads should return the overloads of a template as they
are defined in the language today.
This is the topic of discussion. I argue, that getOverloads can
(so far) act only on functions, because only there the term
overload is well defined. I see, that it could be defined on
templates too, but not in the way you do.
Template overloads are mentioned in the D spec[0], and are
clearly a real thing that it's useful to be able to manipulate.
Yes. But using the term "overload" for templates with the same
name does not justify to wrongly apply existing features to more
abstract objects. This is what you try to do by using
getOverloads with templates.
You seem to be arguing against a feature on the basis that if
the language were significantly different from what it is, the
feature would be confusing. The language isn't that way, so the
feature isn't confusing in that way.
Well, as we both saw with the pragma output, the language is
exactly that way I'm describing it. New getOverload functionality
would introduce a new constraint in comparison to the current
state.
Having getOverloads return template overloads solves a real
issue right now, and would be useful even if your suggested
change were implemented (though the behavior would be slightly
different).
What I'm saying is: it would be useful only then, if my suggested
change were implemented. Otherwise, it is a new constraint and
not a feature.
[0]: https://dlang.org/concepts.html
