Does D have too many features?

[Alex Rønne Petersen]

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