On 04/29/2012 08:31 AM, Paulo Pinto wrote:
Am 28.04.2012 20:47, schrieb Walter Bright:
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?
- two different ways of creating function pointers is confusing
(function and delegate)
I understand the reasoning, but makes one think all the time when
to use what.
'delegate' is more powerful, 'function' is more efficient. If you don't
want to think about it, just use 'delegate'. I'd rather see 'function'
implicitly convert to 'delegate' than to have it gone. D can be used for
systems programming after all!
- sometimes D code looks like template and mixins gone mad
While I do appreciate the power, it can be quite confusing to try
to understand what the code does. Specially with the lack of support
in mixin's debugging
pragma(msg, ...) ?
- misuse of enum to declare constants
I prefer that the use of const would be possible
const infects the type and const-qualified data can exist at runtime, so
it is not possible.
- conditional compilation is hard to follow without syntax highlighting
Other languages with conditional compilation make it easier to follow
what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada
That is not a language issue.
While it is fun to discuss what we like and not like, I vote that
priority should be given to make the language stable and have better
tooling.
We need to have safer languages with native code generation for systems
programming in the mainstream OS, that take us away from the buffer
overflow exploits and dagling pointers legacy that C and C++ brought
upon us.
Someone that does not know D and sees the amount of bugs still existing,
or this type of discussions, will run away to Go or some future version
of C#/Spec#/Bartok, or back to whatever he/she was using before.
I don't agree D is complex, any language that aims to be used in large
application domains, needs a certain set of abstractions. If it does not
support them, it is condemmend to keep getting new features until it
turns in what the language designers were fighting against.
I agree with this section.