higher-order funcs for ranges (with usual interface)

[Lars T. Kyllingstad]

On Thu, 03 Feb 2011 13:05:00 +0100, spir wrote:

> On 02/03/2011 08:41 AM, Lars T. Kyllingstad wrote:
>> On Wed, 02 Feb 2011 18:38:02 +0100, spir wrote:
> 
>>> I guess the only solution would be for the compiler to support a kind
>>> of reange type syntax?
>>
>> I'm not sure I understand what you mean here.  Perhaps you're looking
>> for something like concepts, which have been discussed for both D and
>> C++0x but rejected in both languages:
>>
>>      http://en.wikipedia.org/wiki/Concept_%28generic_programming%29
> 
> Yes, I know about concepts ;-) (and typestates, and such). That's not
> what I mean but I could not find how to express it. What I have in mind
> is a way to simply express <range of T> just like <array of T> is
> expressed by "T[]". But indeed the issue is there is only one type of
> array of T, while there are an infinity of types of ranges of T.
> Your solution below is a good alternative.
> 
>> Anyway, if the source and target range are of the same (known) kind,
>> something like this should work:
>>
>>      struct MyRange(T) { ... }
>>
>>      MyRange!Out map(In, Out)(MyRange!In input, Out delegate(In) f) {
>>          ...
>>      }
>>
>> If they are of different kinds, but still known, this should work:
>>
>>      struct MySourceRange(T) { ... }
>>      struct MyTargetRange(T) { ... }
>>
>>      MyTargetRange!Out map(In, Out)
>>          (MySourceRange!In input, Out delegate(In) f)
>>      {
>>          ...
>>      }
>>
>> Note that I am only talking about what the compiler should be able to
>> figure out through IFTI (implicit function template instantiation), and
>> not about actual implementation.
> 
> Right, this is more or less what I was looking for. And I think I can
> restrict cases to ranges beeing of the same "kind". If necessary, the
> result can then be mapped onto another kind of range (hopefully lazily).
> The only "un-workaround-able" situation is, I guess, when the source
> range is infinite ;-)

Why the reluctance to use template constraints?  They're so flexible! :)

-Lars