Mixin templates are a pain at best, useless at worst for any non-trivial use case

[Ethan]

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?