Does D have too many features?

[simendsjo]

On Mon, 30 Apr 2012 17:35:14 +0200, H. S. Teoh <hsteoh at quickfur.ath.cx>  
wrote:

> On Mon, Apr 30, 2012 at 10:21:23AM +0200, bearophile wrote:
>> H. S. Teoh:
>>
>> >I think the correct solution here is to use alias. (If that doesn't
>> >work, then it should be made to work. It's a lot cleaner and doesn't
>> >introduce potentially nasty ambiguities into code,
>>
>> What ambiguities?
> [...]
>
> When you have nested with's.
>
> Or when the object members shadow local variables in the parent scope.
>
> 	struct S {
> 		int x;
> 	}
>
> 	void main() {
> 		int x, y;
> 		S s;
>
> 		with(s) {
> 			x = 1;
> 			y = 2;
> 		}
> 	}
>
> Technically it's unambiguous which symbols are being referred to, but it
> makes the code hard to read because casual scanning will usually get it
> wrong. Plus, you're entirely at the mercy of the definition of S. If
> it's an imported object from an external library, for example, then when
> upstream makes changes to their struct/class there's a risk of
> introducing subtle errors into existing, correct code (by suddenly
> interpreting an identifier differently). This is never good.
>
> It gets worse with nested with's: when any object being with'd changes,
> you risk identifier collision. The worst thing is that this can happen
> just by upstream(s) changing object definitions, with no change in user
> code.
>
>
> T
>

I think struct literals is worse in this regard:
struct S {
   int a;
   int b;
}

user code:
S(1, 2);

The author of S cleans up the struct and changes the order:
struct S {
   int b;
   int a;
}

Suddely user code has bugs. I believe the reason named parameters hasn't  
been introduced is because the names becomes part of the public interface.  
Well.. With struct literals, the _position_ of the parameters is part of  
the interface.