On 28-04-2012 23:59, H. S. Teoh wrote:
On Sat, Apr 28, 2012 at 11:42:31PM +0200, Peter Alexander wrote:
[...]
- UFCS. It's just sugar, but adds complexity.
On the contrary, it's a major helper for writing generic code. In my new
AA implementation, I use UFCS to provide a default toHash function for
all types that don't already provide one. Without UFCS, this would
require lots of ugly hacks and constraints on how user code can provide
custom hash functions. (Due to the way D overloading works, UFCS is
currently the only way to provide a default function without causing a
conflict at compile-time.)
- const/immutable/inout/shared/pure. These add massive complexity to
the language for little (IMO) benefit. When I do multi-threading, I
usually have to resort to casting. Maybe these will improve with
time.
Yeah they are complex, but they also open ways for powerful
optimizations by the compiler.
I don't know of any production compilers that make significant use of
such annotations in any language. These qualifiers look nice in theory,
but have little practical value other than making it easier to reason
about code.
I don't think they should go away, just sayin'.
(BTW, I think nothing is wrong with pure.)
Though I do have to say that inout needs some serious reconsideration,
since the way they work currently is ambiguous when you have more than
one inout argument, or when you have a delegate parameter with inout
arguments.
- opDispatch. I think it just promotes sloppy, obfuscated code for
minor syntactical benefit.
Wrong. It's a powerful tool for building runtime dynamic class loading.
It allows you to write generic code that Just Works without having to
special-case them for statically-known classes vs. dynamic classes. If
anything, I'd argue for *more* similar features that let you write
generic code that integrates seamlessly into the language.
Just because it's been used (arguably abused) for things like making
roman numerals or vector swizzling, doesn't mean it's a bad feature.
Member access through pointers should require -> like in C++ so that
you can overload it for smart pointer/reference ADTs.
[...]
Yikes!! Please don't reintroduce that monstrous -> operator from C++!
(Besides, most of the time idiomatic D code doesn't even need pointers.)
T
--
- Alex
