best way to handle UFCS with ambiguous names: using std.typetuple.Alias!
ixid
nuaccount at gmail.com
Tue Jun 11 13:37:54 PDT 2013
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/mailman.980.1370764406.13711.digitalmars-d@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);
> }
> ----
It seems like a goofy choice to have two extremely common library
functions share the same name.
More information about the Digitalmars-d-learn
mailing list