Does D have too many features?

[Timon Gehr]

On 04/29/2012 01:25 AM, foobar wrote:
> On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
>> On 04/28/2012 09:58 PM, foobar wrote:
>>> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
>>>> Andrei and I had a fun discussion last night about this question. The
>>>> idea was which features in D are redundant and/or do not add
>>>> significant value?
>>>>
>>>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>>>> and creal types.
>>>>
>>>> What's your list?
>>>
>>> D has a lot of ad-hock features which make the language
>>> needlessly large and complex. I'd strive to replace these with
>>> better general purpose mechanisms.
>>>
>>> My list:
>>> * I'd start with getting rid of foreach completely. (not just
>>> foreach_reverse).
>>
>>
>> foreach is very useful. Have you actually used D?
>>
>
> I have used D and didn't claim that foreach isn't useful.
> What I said that is that it belongs in the library, NOT the language.
>

Therefore you say that it is not useful as a language feature.

>>> This is nothing more than a fancy function with
>>> a delegate parameter.
>>>
>>
>> That would be opApply.
>
> 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!)

>>
>>> * 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.

> 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.

>>
>>> * version - this does not belong in a programming language. Git
>>> is a much better solution.
>>>
>>
>> So you'd maintain a git branch for every OS if there is some small
>> part that is OS-dependent? I don't think that is a better approach at
>> all.
>
> It is far better than having a pile of #ifdef styled spaghetti code.
> I'd expect to have all the OS specific code encapsulated separately anyway,
> not spread around the code base. Which is the current recommended way of
> using
> versions anyway. The inevitable conclusion would be to either use a
> version management system like git or have separate implementation
> modules for platform specific code and use the build tool to implement
> the logic of select the modules to include in the build.
>

Which projects you are aware of actually use this kind of versioning?

>>
>>> * di files - a library should encapsulate all the info required
>>> to use it. Java Jars, .Net assemblies and even old school; Pascal
>>> units all solved this long ago.
>>>
>>> * This is a big one: get rid of *all* current compile time
>>> special syntax.
>>
>> What would that be exactly?
>
> This includes __traits, templates, static ifs, etc..
>

This is what makes D useful to me.

>>
>>> It should be replaced by a standard compilation
>>> API and the compiler should be able to use plugins/addons.
>>
>> Are you serious?
>
> No I'm joking.
>
> The current system is a pile of hacks on top of the broken model of c++
> templates.
>
> 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.