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".
