Does D have too many features?

Peter Alexander peter.alexander.au at gmail.com
Sat Apr 28 15:27:15 PDT 2012


On Saturday, 28 April 2012 at 21:58:47 UTC, 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.)

The problem there is that toHash is a member function. That UFCS 
is helpful in working around other problems in D is not a good 
argument for its existence IMO.

To be honest, I don't like the idea of member functions at all. 
Having two syntaxes for calling a function is the core problem, 
and UFCS is just an extra complication on top of it to try and 
mitigate the original problem.

f(x) ---> x.f() is not progress in language design.


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

In theory. IMO the amount of time you spend trying to please the 
type system could have been better spent optimizing your code 
manually.

No code I have ever written would benefit significantly from 
these potential optimisations. For example, one optimisation is 
that pure function calls could be hoisted out of loops. Great, 
except that if that function call had any significant cost 
whatsoever, I would have already done that optimisation myself.


>> - opDispatch. I think it just promotes sloppy, obfuscated code 
>> for
>> minor syntactical benefit.
>
> Wrong.

It's my opinion. You are free to disagree, but opinions can't be 
wrong.

I've seen no good uses of opDispatch so far. If you can point me 
towards some code that justifies its use then please let me know 
about it.




More information about the Digitalmars-d mailing list