Scenario: OpenSSL in D language, pros/cons

[Daniele M. via Digitalmars-d]

On Monday, 5 May 2014 at 10:41:41 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
> 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

You nailed it. If we wanted to translate the theoretical exercise 
into something real, it would be nice to have an implementation 
of PolarSSL that works on ring buffers only, then leave network 
layer integration to clients. Much cleaner separation of concerns.