Programming Language for Games, part 3

[Walter Bright via Digitalmars-d]

On 11/1/2014 6:25 PM, bearophile wrote:
> As the designer of the language you have to look at code written by other people
> too! Because your D code is probably very different from mine. Take a look at
> Haskell code, Rust code, Erlang code, and learn new idioms and new paradigms. In
> the long run this will help D more than fixing a couple more bugs.

I don't see the use cases, in mine or other code. There's a reason why people 
always trot out printf - it's about the only one. Designing a language feature 
around printf is a mistake.


>> it is very rare that I pass arguments to functions that would benefit from
>> compile time checking.
>
> To me this happens. It doesn't happen all the time. As usual it's not easy to
> quantify the frequency of such cases. (On the other hand your "very rare" is
> unsupported by statistical evidence as well. Your judgement is probably better
> than mine, of course and I respect your opinions).

I've considered the feature, and looked at code. It just doesn't happen very often.

All features have a cost/benefit to them. The costs are never zero. Laying on 
more and more features of minor benefit will destroy the language, and even you 
won't use it.


>> For those that might, there's always a rethinking of the
>> feature, such as with printf/writefln.
>
> I regard D writefln as currently _broken_.

Oh come on. writefln is typesafe and will not crash.

You could also write:

    formattedwrite!"the format string %s %d"(args ...)

if you like. The fact that nobody has bothered to suggests that it doesn't add 
much value over writefln().