[Issue 14125] @trusted nested helper functions in std.file

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Feb 4 22:32:26 PST 2015


https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #67 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to Dicebot from comment #65)
> (In reply to Andrei Alexandrescu from comment #62)
> > I don't see how this is pushing your argument further. Make a technical
> > point and it'll be well appreciated.
> 
> Big chunks of @trusted are maintenance disaster.

Agreed.

> @trusted completely
> disabled all compiler safety verification and because of that every time a
> single line changes in @trusted function it must be completely re-evaluated
> as a whole during the review to ensure that safety promise stays.

I understand. To summarize: there is merit in marking a function as @safe even
though it has a few non-safe portions because the compiler can at least verify
those non-safe portions. So, the argument goes, we get a bit more interstitial
verification.

That's also the case with functions such as trustedOpen, trustedFstat,
trustedRead, trustedRealloc, trustedPtrAdd (urgh!), trustedPtrSlicing. Any code
added may use them and needs to be checked for safety. I hope this is
understood as well.

> Situation
> becomes worse because compiler is very conservative in what it considers
> reliably @safe and thus amount of necessary at trusted functions is very big.
> Combined, that makes using @trusted in a way you propose so impractical that
> resource-wise it is more effective to completely ignore @safe feature at all
> - it does not provide enough benefits for such investment.
> 
> Does that sounds technical enough?

Yes, thanks. It is also not convincing, as it seems my arguments are not
convincing to you.

Again it is getting clear we are reaching irreducible positions on this so
arguing the point is not productive. New arguments might change this, so feel
free to bring any fresh perspective on the subject. I believe I have a good
understanding of your current points. 

This must go one way or another; it can't go both ways.

If you were responsible I trust you would do what you think is best over my
unconvincing arguments, and let me decide how to handle your decision in good
form. As things are Walter and I must do what we believe is best (starting with
https://github.com/D-Programming-Language/phobos/pull/2963) and I trust you
will handle our decision in good form. Thank you.

--


More information about the Digitalmars-d-bugs mailing list