Does D have too many features?

foobar foo at bar.com
Sun Apr 29 02:31:43 PDT 2012


On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:
>>[...]
>> Indeed but I'd go even further by integrating it with ranges 
>> so that
>> ranges would provide an opApply like method e.g.
>> auto r = BinaryTree!T.preOrder(); // returns range
>> r.each( (T elem) { ...use elem...}); // each method a-la Ruby
>>
>
> Well, I don't think this is better than built-in foreach (with 
> full break and continue and goto even for user-defined opApply!)

I think we reached a matter of taste here. How often do you use 
these features anyway in your regular code? I prefer a more 
functional style with higher order functions 
(map/reduce/filter/etc..) so for me foreach is about applying 
something to all elements and doesn't entail usage of 
break/continue/etc..
I'll use these constructs in a for loop but not a foreach loop.

>
>>>
>>>> * enum - enum should be completely redesigned to only 
>>>> implement
>>>> what it's named after: enumerations.
>>>>
>>>
>>> What is the benefit?
>>
>> On the one hand the current enum for manifest constants is a 
>> hack due to
>> weaknesses of the toolchain
>
> I think that is actually not true. It might have been the 
> original motivation, but it has gone beyond that. Which 
> weaknesses in particular? I don't think that the toolchain can 
> be improved in any way in this regard.

The weakness as far as I know is about link time optimization of 
constants.
But regardless, my ideal implementation of so called 
"compile-time" features, including compile time constants, would 
be very different anyway.

>
>> and on the other hand it doesn't provide
>> properly encapsulated enums
>
> Those could in theory be added without removing the manifest 
> constant usage.
>
>> such as for instance the Java 5.0 ones or
>> the functional kind.
>>
>
> An algebraic data type is not an 'enumeration', so this is a 
> moot point.

I disagree. They are a generalization of the concept. In fact, 
functional languages such as ML implement c style enums as an 
algebraic data type.

>>[...]
>>
>> I should be able to use a *very* minimalistic system to write 
>> completely
>> _regular_ D code and run it at different times.
>
> Examples in concrete syntax? How would you replace eg. string 
> mixin functionality?
>
>
>> This is a simple matter
>> of separation of concerns: what we want to execute (what code) 
>> is
>> separate to the concern of when we want to execute it.
>>
>
> It is not. For example, code that is only executed during CTFE 
> does never have to behave gracefully if the input is ill-formed.

I disagree - you should make sure the input is valid or all sorts 
of bad things could potentially happen such as a compiler can get 
stuck in an infinite loop. If you only use a batch mode compiler 
you can simply kill the process which btw applies just the same 
to your user program. However, if you use an integrated compiler 
in your IDE that could cause me to lose part of my work if the 
IDE crashes.


More information about the Digitalmars-d mailing list