Am 29.10.2010 13:54, schrieb tls:
Jonathan M Davis Wrote:On Friday 29 October 2010 03:06:56 dennis luehring wrote: > Am 29.10.2010 11:07, schrieb Denis Koroskin: > > On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehring<dl.so...@gmx.net> > > No one is talking about removing nullable references but rather adding > > non-nullable types and making them default. You could still achieve old > > behavior if it is needed (most proposed proposed syntax): > > > > Foo? foo = stuff.find(predicate); > > if (foo is null) { > > > > // not found > > > > } > > > > No one is talking about removing nullable references > > sorry > > > most proposed proposed syntax > > like it works in C# - but better because of "...and making them default." > :) > > sound very similar to the long talked about "make parameters const per > default" proposal - which is also still not there :( Personally, I think that both would be horrible. Having const is great, and having non-nullable references could be great, but I sure wouldn't want them to be the default. In addition to that, however, having them as the default would make porting code from other C-based languages a total nightmare - not to mention it totally shatters the general principle that either C/C++ code is valid D code with the exact same behavior it doesn't compile. That alone makes making them the default untenable.Sometime not having safety is better. You see I write now GUI program for users uses xview toolkit. xview using k&r C (http://bytes.com/topic/c/answers/215340-k-r-style-function-declarations-good-bad). I very sad find D not support standard k&r C so me consider update dmd frontend to support k&r C. much easy to read: void * newKlElem (frame_size,num_blocks,num_frames,frame_locator) size_t frame_size; unsigned short num_blocks; unsigned short num_frames; Kl_frame_locator *locator; { instead modern confuser sintax. This show how important support legacy is. Cost many hours writing new dmd frontend. If also const broken and nulls then this coode won't run at all! No good. Keep legacy.
sorry but your arguments are loosing any sense, to add K&R support only because of the ease to port an very old style code is nothing more then stupid 100% ... sorry, but you should not involve yourselfe in language design dicussion
