Does D have too many features?

[Timon Gehr]

On 05/01/2012 12:54 AM, Kapps wrote:
> On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
>>
>> I'm surprised nobody has mentioned opApply. That was a good idea at
>> the time, but Ranges are a superior solution. I'd like to see new code
>> not use opApply. It's a dead end, though it'll still be supported for
>> a long time.
>
> I practically never use ranges, and instead use opApply for all my code.
>
> 1) Ranges force me to use a specific naming convention. My naming
> convention that I use for my projects is upper camel case. Ranges do not
> allow this.

Yes they do. (If you are willing to have both kinds of symbols around.)

mixin template AddAliasesForBuiltInRange(){
     alias Front front;
     alias Empty empty;
     alias PopFront popFront;
}

struct R{
     ...
     @property Front(){...}
     @property bool Empty(){...}
     void PopFront(){...}

     mixin AddAliasesForBuiltInRange;
}


> Technically opApply is still lower camel case, but my code
> doesn't directly call it.
>

The same would hold for the above example.

> 2) Ranges don't have a way of determining when the iteration ends.
> Sometimes you want to do something once iteration stops. For example, by
> far the most common action when executing a database call for me, is to
> iterate over it and close it. I can then have a helper method that
> executes the command and closes it when the foreach is done (whether by
> break or by the function ending). This saves quite a bit of boiler plate
> code.
>

An important point.

> 3) Ranges can be difficult to implement. You now have to keep track of
> state instead of simply leaving everything inside a single method call.
> This can also cause significant problems with multi-threaded code.
>
> 4) Ranges take a lot more code, which when all you want is basic
> iteration, is pointless to have
>

Those two could be mitigated by moving the range concept further into 
the language.

> I'd much rather just see things with opApply being able to have a
> forward-range magically created for it, much like the reverse. Not sure
> if this is possible or practical though.
>

Am implementation (that is possible now) could use coroutines 
(core.thread.Fiber), but that is not very efficient for simple 
iteration. Compiler support would be a solution. See eg. C# yield 
return. (In D the compiler would generate anonymous struct types instead 
of IEnumerable interface implementations).