Mark std.file.readText as trusted

[tom-tan]

std.file.readText includes an unsafe cast from void[] to string but we can verify it can be trusted.

[mihails-strasuns]

Looks like this is missing template constraint if(isSomeString!S), this cast + validate does not make sense for any other types.

[tom-tan]

Thank you for your suggestion.
I added a constraint if for it.

[JakobOvrum]

Shouldn't the call to validate be in the trusted portion as well? That way, whatever the input to the trusted code, we can verify the output is valid UTF text. That seems to be the original purpose of these trusted subroutines in the first place, otherwise we're just doing it to fight the compiler.

[mihails-strasuns]

Erm. any reason why validate can't be / shouldn't be @safe?

[tom-tan]

We do not need wrap validate in a trusted block because it is a safe function.

[JakobOvrum]

Erm. any reason why validate can't be / shouldn't be @safe?

It should be @safe.

We do not need wrap validate in a trusted block because it is a safe function.

Ideally we're not using nested functions just to fight the compiler.

As-is, the @trusted portion of the code is not where the runtime-checked safety occurs. It occurs in the parent function.

[mihails-strasuns]

As-is, the @trusted portion of the code is not where the runtime-checked safety occurs. It occurs in the parent function.

Sorry this is exactly the part I don't understand. @safe is about memory safety. Only part of this code that is in general memory-unsafe is cast expression. However casting specifically void[] buffer to some string type is always memory-safe so we mark exactly that expression as trusted.

Validation is not relevant here because malformed unicode string is still memory-safe.

[JakobOvrum]

Indeed you don't seem to understand what I'm saying.

But nevermind, it's rare that we have the opportunity to completely encapsulate unsafe code in a neat little trusted block, so it's not really useful to advocate in general...

[mihails-strasuns]

Well I am very confused by your mention of "runtime-checked safety" because there are none here - this code is statically safe, it is just that compiler is not clever enough to consider this cast safe.

[dnadlinger]

LGTM – could you please squash the commits together? Thanks!

[tom-tan]

I squashed the commits.

[dnadlinger]

Auto-merge toggled on

[tom-tan]

Thanks!

[JakobOvrum]

Shouldn't the call to validate be in the trusted portion as well? That way, whatever the input to the trusted code, we can verify the output is valid UTF text. That seems to be the original purpose of these trusted subroutines in the first place, otherwise we're just doing it to fight the compiler.

In light of the recent @trusted debacle... so was I right after all? :)

[schveiguy]

In light of the recent @trusted debacle... so was I right after all? :)

Not exactly. I think the whole thing should be trusted, it's pretty small.