On Mon, 05 May 2014 10:24:27 +0000 via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 5 May 2014 at 09:32:40 UTC, JR wrote: > > On Sunday, 4 May 2014 at 21:18:24 UTC, Daniele M. wrote: > >> And then comes my next question: except for that malloc-hack, > >> would it have been possible to write it in @safe D? I guess > >> that if not, module(s) could have been made un-@safe. Not > >> saying that a similar separation of concerns was not possible > >> in OpenSSL itself, but that D could have made it less > >> development-expensive in my opinion. > > > > TDPL SafeD visions notwithstanding, @safe is very very limiting. > > > > I/O is forbidden so simple Hello Worlds are right out, let > > alone advanced socket libraries. > > I/O is not forbidden, it's just that writeln and friends > currently can't be made safe, but that is being worked on AFAIK. > While I/O usually goes through the OS, the system calls can be > manually verified and made @trusted. As the underlying OS calls are all C functions, there will always be @system code involved in I/O, but in most cases, we should be able to wrap those functions in D functions which are @trusted. Regarldess, I would think that SSL could be implemented without sockets - that is, all of its operations should be able to operate on arbitrary data regardless of whether that data is sent over a socket or not. And if that's the case, then even if the socket operations themselves had to be @system, then everything else should still be able to be @safe. Most of the problems with @safe stem either from library functions that don't use it like they should, or because the compiler does not yet do a good enough job with attribute inference on templated functions. Both problems are being addressed, so the situation will improve over time. Regardless, there's nothing fundamentally limited about @safe except for operations which are actually unsafe with regards to memory, and any case where something isn't @safe when it's actually memory safe should be and will be fixed (as well as any situation which isn't memory safe but is considered @safe anyway - we do unfortunately still have a few of those). - Jonathan M Davis