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-@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~ :< )
