Change representation of dynamic arrays?

[Daniel Keep]

Janice Caron wrote:
> On 10/20/07, Oskar Linde <oskar.lindeREM at ovegmail.com> wrote:
>>> 1) Passing dynamic arrays to printf as in:
>>>
>>>     printf("my string is %*.s\n", str);
>> I'm glad that breaks. That code was never portable anyway
> 
> I'd be happy for it to break if the break could be detected at compile
> time (or even at runtime with an assert). I'm not terrifically happy
> that source code that previously generated code that ran just fine
> would now generate code that will simply crash with no explanation.

You're calling a function that completely bypasses the type system, and
you want compile-time checking on it? :S  If you're going to play with
fire (type-unsafe variadic C functions), you shouldn't be surprised when
you get third-degree burns.  ;)

> You have to remember that there was once a time when writef() and
> family did not exist, and that printf("%.*s") was the /recommended/
> way of doing things, documented as such on the Digital Mars site. So
> you cannot blame anyone for using that idiom, say, three or four years
> ago.

This is true, but remember that this is for D 2.0.  If someone honestly
expects to be able to take code written three years ago when the
language was still in flux (and which, mind you, likely won't even
compile with the current 1.0 compiler) and compile it on 2.0 without
issues is, in my opinion, delusional.

> I'd be all in favor making any use of printf a compile error - say by
> making a global function which takes no parameters (forcing coders to
> explicity qualify the function name if they wanted to C printf). Note
> that this reasoning also applies to vprintf, fprintf, vfprintf,
> sprintf, snprintf, etc., etc...

I think that removing it from object so that it can't be used without
explicitly importing it would be sufficient.

Maybe sticking a deprecated attribute on the printf declaration would
also help.  Maybe with a message saying "No, you want writef.  Seriously."

	-- Daniel