Does D have too many features?

[Timon Gehr]

On 04/30/2012 05:45 AM, H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 04:40:37PM +0200, Jacob Carlborg wrote:
> [...]
>
> So really, what is needed is a sane looping construct that unifies while
> loops, do-loops, and exit-in-the-middle loops. Something like this:
>
> 	loop {
> 		// first part of loop body
> 	} exitWhen(!loopCondition) {
> 		// second part of loop body
> 	}
>
> It doesn't have to be this exact syntax, but the point is that you need
> to be able to express loop exits from the middle of a loop body without
> needing to resort to for(;;) and break, when the loop is a good ole
> simple loop with a single entry point and a single exit point. (More
> complex loops that need continue's and break's are, well, more complex,
> so it's OK to sprinkle if conditions in them like we do now.)
>
> </rant>
>

do{
     // ...
}while(cond){
     // ...
}

I think the scoping rules of the do-while loop should be fixed such that 
the loop condition can refer to loop-local variables. Violates C 
backwards compatibility though...


>
> [...]
>> * 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.
> [...]
>
> While personally, I like the idea of being able to create new infix
> operators, it will cause too big a change to D syntax, and probably
> cause lots of breakages with existing code, as well as make the
> lexer/parser much harder to implement (given the existing D features).
>

Should be trivial. (The parser can just defer operator precedence 
resolution to the analysis phase if necessary, and otherwise it is very 
simple anyway.)

> You also then have to deal with operator precedence between arbitrary
> user-defined operators, which is non-trivial in general (though it's
> workable if you impose some constrains

I kinda like the Scala-approach.

> -- but it's probably way beyond the scope of D2 or even D3).
>

An issue is that it clashes with eg. a+***ptrtoptrtoptrtodata.