On Tuesday, 5 June 2018 at 12:08:58 UTC, Simen Kjærås wrote:
There's a reason for those rules in the language, namely
function hijacking. This is an issue we take very seriously,
and workarounds exists.
So serious that there is no meaningful error message?
These issues can be ameliorated as in your other post here, by
wrapping the template mixin statement as well. This leads to a
host of other problems - how do you specify arguments to the
mixin template? How do you deal with aliased mixin templates?
These issues may possibly be fixed, but it's gonna get ugly.
I've posted on these newsgroups literally within the last three
weeks about dealing with multiple different argument types
(parsing template parameters) and aliases (__traits( identifier,
Symbol ) does not match Symbol.stringof if it is an alias). As
such, that's purely within the realms of "solvable by the
programmer with new idioms" as I see it.
This thing I'm posting about is solvable by giving up and
generating a string to treat as code. ie the nuclear option when
everything else in the language is unsuitable.
This issue shows up every now and then, so we know it's a real
issue, and the workarounds are clunky. At the same time, the
current behavior is there for a reason, and is very unlikely to
change.
https://dlang.org/spec/template-mixin.html
1. A TemplateMixin takes an arbitrary set of declarations from
the body of a TemplateDeclaration and inserts them into the
current context.
Everything you've talked about here directly conflicts with point
number 1 of the mixin template spec. Point 3 of the spec makes a
note of the implementation not actually doing the direct
copy/paste that it mentions and instead embeds it in to a nested
scope and imports it after the fact. Yet there appears to be
quite a number of "except for this" clauses that aren't made
clear. Clearly something has gone wrong somewhere along the way.
So by that token: How many real world dollars have been wasted on
function hijacking? Is this something a corporate client has been
adamant about? Bringing up the #define macro analogy again, these
are clearly similar problems that can happen in C/C++. So is it
more of an ideological stand than a real-world one?
