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.
