On Monday, 10 June 2013 at 02:02:09 UTC, Timothee Cour wrote:
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/[email protected]',
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);
}
----
It seems like a goofy choice to have two extremely common library
functions share the same name.
