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