A safer interface for core.stdc

[H. S. Teoh via Digitalmars-d]

On Sat, Feb 07, 2015 at 08:14:39PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2/7/15 7:52 PM, tcak wrote:
> >One of the reasons why I use C functions is that I expect same
> >behaviour from D code what I would expect from C. I don't think it is
> >a good idea to make wrapper on top of them. Maybe you could say,
> >"Hey, look, it just makes safer, that's all", but, hmm there are so
> >many functions, and this wrapping process can go in many directions.
> 
> Just looking at making them safe. Not all can be made safe btw. --
> Andrei

Come to think of it, is there any point in making malloc @safe/@trusted
at all? I don't think it's possible to make free() @safe, so what's the
purpose of making malloc callable from @safe code? Unless you make a
ref-counted wrapper of some sort around it, in which case you might as
well use RefCounted instead.

I thought about making the equivalent of auto_ptr, but unless you make
it non-copyable (or only destructively copyable, and no pointer
extraction is permitted), there's no way it can be truly @safe.

The only possible advantage we could gain is *type* safety by wrapping
malloc in a type-safe way (i.e., don't expose void*).


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".