Does D have too many features?

Alex Rønne Petersen xtzgzorex at gmail.com
Sun Apr 29 14:04:26 PDT 2012


On 29-04-2012 16:40, Jacob Carlborg wrote:
> On 2012-04-28 20:47, 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?
>
> * Some of the built-in properties could probably be move to a library
> solution, specially now when we have UFCS.

+1.

>
> * The with-statement isn't particular useful. Although I've started to
> use it in one of my projects just so I don't have to use fully qualified
> enum names.

It is very useful in some cases where you operate a lot on the same object.

>
> * D embedded in HTML (don't know if this is still supported)

Madness... I think it's deprecated now.

>
> * Multiple syntax for wysiwyg strings. I think the r"" syntax can be
> remove.
>
> * Do-while loops, how useful are those actually?

I use them occasionally, but it's certainly true that they are rarely 
useful.

>
> Then I think some features could be replaced with library solutions if D
> got some other features. For example:
>
> * foreach(_reverse)
> * synchronized
>
> These could probably be removed in favor of library solutions.
>
> void foreach (T)(T[] arr, void delegate (ref T) dg)
> {
> for (size_t i = 0; i < arr.length; i++)
> dg(arr[i]);
> }
>
> foreach ([1, 2, 3, 4], (i) { writeln(i); });
>
> The above already works today. If we can a bit syntax sugar for
> delegates and inlinable delegates we could have this:
>
> foreach ([1, 2, 3, 4] ; i) {
> writeln(i);
> }
>
> The above syntax would be very useful in other cases as well.
>
> The same could be done for "synchronized" as well. Might even be
> possible to remove the for-statement and just have "while" left.
>
> I we want get even more wild and crazy I think Scala's solution for
> operator overloading looks really good. But that would require several
> other features to work. Like:
>
> * Everything is an object (might not be needed with UFCS)
> * Everything is a method call on an object
> * Infix notation for calling any method taking one argument
> * Basically any symbol is allowed in method names
>
> That is:
>
> 1 + 2
> foo bar foo_bar
>
> Would be translated to:
>
> 1.+(2)
> foo.bar(foo_bar)
>
> That is a very general way to handle operators and let the user create
> new operators, not just overloading existing ones.
>


-- 
- Alex


More information about the Digitalmars-d mailing list