Scenario: OpenSSL in D language, pros/cons

[Jonathan M Davis via Digitalmars-d]

On Mon, 05 May 2014 10:24:27 +0000
via Digitalmars-d <digitalmars-d at 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- at 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