Scenario: OpenSSL in D language, pros/cons

[JR via Digitalmars-d]

On Monday, 5 May 2014 at 15:01:05 UTC, Andrei Alexandrescu wrote:
> On 5/5/14, 2:32 AM, 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.
>
> Sounds like a library bug. Has it been submitted? -- Andrei

When mentioned in #d it was met with replies of "well 
*obviously*", so I chalked it up to an irreconcilability of 
@safe's. Perhaps I'm expecting too much of the subset.

My code certainly does no pointer arithmetic, but adding @safe: 
in select locations quickly shows that string operations like 
indexOf are unsafe, as is everything in concurrency (including 
thisTid), getopt, std.conv.to (to avoid casts), and all socket 
operations. All of those can throw, but I don't see how they can 
corrupt memory.

Apologies for the negativity. It's not that much of a deal, but 
your code will have to be very unreliant upon phobos to be 
completely @safe. I appreciate these threads gauging community 
reactions and I hope the mood will be lighter post-dconf, but at 
present there's still a sour taste left in my mouth after the 
final-by-default pivot.

(Manu and Thaut, please don't leave~ :<   )