best way to handle UFCS with ambiguous names: using std.typetuple.Alias!

[Timothee Cour]

UFCS chains are problematic when a symbol is ambiguous (eg after import
std.stdio:write;import std.file:write);

I previously suggested to add the syntax
'arg1.(std.file.write)(arg2)'
(see 'support UFCS with fully qualified function names (was in
"digitalmars.D.learn")'  to avoid breaking UFCS chains.

Others have suggested using renamed local imports:
import std.file:write2=write;
'arg1.write2(arg2)'

This issue keeps coming up, eg '
http://forum.dlang.org/post/mailman.980.1370764406.13711.digitalmar...@puremagic.com',
prompting some to prefer symbols with unique, redundant names eg
std.compress.lzw.lzwCompress instead of std.compress.lzw.compress.

However I found a much better way:

*import std. typetuple:Alias;*
*'arg1.Alias!(std.file.write).arg2'*

Interestingly, I haven't found this pattern in phobos.

advantage:

* UFCS chain not broken; no loss of efficiency
* library solution, already works, no need to add new syntax
* avoids the renamed local imports, which I argue is a bad idea (makes it
harder to search for usages of a function, ie 'grep' won't work)
* systematic way to handle the such cases, whereas renamed local imports
require to 'guess' a good name, eg import std.file:write2=write;
* renamed local imports require 1 import declaration syntax per ambiguous
UFCS function (eg import std.file:write2=write needed even if import
std.file is already there), whereas a single import std.typetuple
declaration handles all ambiguous cases).

Bigger example:
----
void main(){
import std.typetuple;

import std.stdio;
import std.file;
import std.range;
import std.algorithm;

"hello2".Alias!(std.stdio.write);
3.iota.map!(a=>a*a).Alias!(std.algorithm.reduce!"a+b").Alias!(std.stdio.writeln);
}
----