Can we get rid of opApply?

Max Samukha samukha at voliacable.com.removethis
Tue Jan 20 23:36:02 PST 2009


On Tue, 20 Jan 2009 09:32:01 -0800, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:

>Max Samukha wrote:
>> On Tue, 20 Jan 2009 11:36:47 -0500, "Steven Schveighoffer"
>> <schveiguy at yahoo.com> wrote:
>> 
>>> "dsimcha" wrote
>>>> foreach(char[] s; array) vs.
>>>> foreach(char[] s; IntegersAsString(array))
>>>>
>>>> I think a lot of stuff is going to need some kind of extra struct like 
>>>> this to
>>>> make it work.  When this is the case, it needs to be possible to have a 
>>>> default
>>>> iteration method that "just works."  The opDot overload, I guess, could do 
>>>> this,
>>>> but it's a rather blunt tool, since then you can't use opDot for other 
>>>> stuff and
>>>> you'd have to forward _everything_ to the opDot object.
>>> opRange doesn't help here.  array is a (non-extendable) primitive, so the 
>>> compiler needs to be told how to convert integers to strings.
>>>
>>> Even opApply wouldn't get you here.
>>>
>>> I actually think something cool would be a toRange struct:
>>>
>>> foreach(s; toRange!(string)(array))
>>>
>>> Which would be like the to! template.
>>>
>>> -Steve 
>>>
>> 
>> That could be easily implemented with the lazy map:
>> 
>> auto toRange(T, R)(R r)
>> {
>>   alias ElementType!(R) E;
>>   return mapLazy!((E a){ return to!(T)(a); })(r);
>> }
>> 
>> BTW, is there a way to alias a function template instantiation?
>
>template toRange(T) { alias map!(to!T) toRange; }
>
>Andrei

Nice!



More information about the Digitalmars-d mailing list