The more interesting question

[Alex Rønne Petersen]

On 16-05-2012 16:25, Gor Gyolchanyan wrote:
> On Wed, May 16, 2012 at 6:10 PM, Alex Rønne Petersen <alex at lycus.org
> <mailto:alex at lycus.org>> wrote:
>
>     On 16-05-2012 16:04, Gor Gyolchanyan wrote:
>
>         On Wed, May 16, 2012 at 5:25 PM, Steven Schveighoffer
>         <schveiguy at yahoo.com <mailto:schveiguy at yahoo.com>
>         <mailto:schveiguy at yahoo.com <mailto:schveiguy at yahoo.com>>> wrote:
>
>             On Tue, 15 May 2012 18:31:26 -0400, deadalnix
>         <deadalnix at gmail.com <mailto:deadalnix at gmail.com>
>         <mailto:deadalnix at gmail.com <mailto:deadalnix at gmail.com>>> wrote:
>
>                 Le 15/05/2012 17:51, Christophe a écrit :
>
>                     deadalnix , dans le message (digitalmars.D:167404),
>         a écrit :
>
>                         This looks to me like a bad practice. C string and D
>                         string are
>                         different beasts, and we have toStringz .
>
>
>                     C string and D string are different, but it's not a
>         bad idea
>                     to have
>                     string *literals* that works for both C and D strings,
>                     otherwise using
>                     printf will lead to a bug each time the programmer
>         forget
>                     the trailing
>                     \0.
>
>
>                 Due to slicing, it is already unsafe to pass a D string to C
>                 code. The main problem is array casting silently to
>         pointers,
>                 making the error easy to do.
>
>
>             How so?  strings are immutable, and literals are *truly*
>         immutable.
>
>
>                 Fixing the problem for literal isn't going to solve it
>         at all.
>
>                 The real solution is toStringz
>
>
>             toStringz can allocate a new block in order to ensure 0 gets
>         added.
>               This is ludicrous!
>
>             You are trying to tell me that any time I want to call a C
>         function
>             with a string literal, I have to first heap-allocate it,
>         even though
>             I *know* it's safe.
>
>             I don't see a "problem" anywhere.  The current system is
>         perfect for
>             what it needs to do.
>
>             -Steve
>
>
>         Aside from the string problem the very existence of this debate
>         exposes
>         a fundamental flaw in the entire software engineering industry:
>         heavy
>         usage of ancient crap.
>         If some library is so damned hard to refresh, then something's
>         terribly
>         wrong with it. It's about damned time ancient libraries are
>         thrown away.
>
>         --
>         Bye,
>         Gor Gyolchanyan.
>
>
>     I... don't think that's a very pragmatic view.
>
>     Yes, software sucks. Deal with it, etc.
>
>
>     --
>     Alex Rønne Petersen
>     alex at lycus.org <mailto:alex at lycus.org>
>     http://lycus.org
>
>
> Deal with it? That's the attitude that made it this way in the first
> place. If you like having software this way till the end of times - be
> my guest. I for one will not tolerate this unacceptably obsolete
> software. If you want it to stop being this bad - you're welcome to join
> me in the effort to put an end to this. It seems impossible only because
> nobody actually tried doing anything and all everybody does is complain
> about ancient stuff still requiring compatibility. With some effort that
> can be changed. Ancient libraries still require compatibility not
> because it's a rule, but because there are people who use them. They use
> them because there are no alternatives. If some people deliberately
> refuse to embrace the progress - it's their damned problem.
>
> --
> Bye,
> Gor Gyolchanyan.

C support and interoperability has always been a goal of D; and I don't 
see that changing.

That's not saying that reimplementing these libraries in D is a bad idea 
- in fact, it would make everyone's lives easier. So by all means, do 
that. But I'm using some libraries such as libgc (the 
Boehm-Demers-Weiser GC) and libffi (foreign function interface for C) 
that would take eons to port, audit, test, ... and I have a project that 
depends on them that I need to work on.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org