On 7/26/15 9:11 AM, Dicebot wrote:
I remember doing something like that in druntime because of objects -
you can't override @safe method prototype with @trusted one.
But you can, at least now you can, maybe it's changed.
In answer to the original question, the given code is quite unnecessary.
Am Sun, 26 Jul 2015 13:11:51 +
schrieb "Dicebot" :
> I remember doing something like that in druntime because of
> objects - you can't override @safe method prototype with @trusted
> one.
>
That's probably related to the fact that safe and trusted functions
have different mangled names. Th
I remember doing something like that in druntime because of
objects - you can't override @safe method prototype with @trusted
one.
On 26/07/15 14:24, Adam D. Ruppe via Digitalmars-d-learn wrote:
If the whole function is marked @trusted, the compiler doesn't try to check it
at all - it just takes your word for it.
There was a bit of argument about this a while ago in bugzilla, not everyone
agrees it is a good idea. I don't r
On Sunday, 26 July 2015 at 11:38:31 UTC, simendsjo wrote:
Is there a reason why you would hide the fact that a function
is trusted rather than safe? Technically it doesn't matter,
right? To me, it seems like this would give wrong assumptions
to the caller.
The Phobos idiom you've seen there i
On Sunday, 26 July 2015 at 11:38:31 UTC, simendsjo wrote:
Is there a reason why you would hide the fact that a function
is trusted rather than safe? Technically it doesn't matter,
right? To me, it seems like this would give wrong assumptions
to the caller.
The reason I ask is because I found
Is there a reason why you would hide the fact that a function is
trusted rather than safe? Technically it doesn't matter, right?
To me, it seems like this would give wrong assumptions to the
caller.
The reason I ask is because I found the following in
std.concurrency:
@property Tid this
